Monitoring the Service


Monitoring the Service
 
This chapter provides information for monitoring service status and performance using the show commands found in the Command Line Interface (CLI). These command have many related keywords that allow them to provide useful information on all aspects of the system ranging from current software configuration through call activity and status.
The selection of keywords described in this chapter is intended to provided the most useful and in-depth information for monitoring the system. For additional information on these and other show command keywords, refer to the Command Line Interface Reference.
In addition to the CLI, the system supports the sending of Simple Network Management Protocol (SNMP) traps that indicate status and alarm conditions. Refer to the SNMP MIB Reference for a detailed listing of these traps.
Monitoring System Status and Performance
This section contains commands used to monitor the status of tasks, managers, applications and other software components in the system. Output descriptions for most of the commands are located in the Counters and Statistics Reference.
System Status and Performance Monitoring Commands
dns-client query client-name client_name query-type AAAA query-name <p-cscf.com>
context egress_pgw_context_name
context ingress_pgw_context_name
context egress_pgw_context_name
context egress_pgw_context_name
context ingress_pgw_context_name
Important: Refer to the System Software Task and Subsystem Descriptions appendix in the System Administration Guide for additional information on the Session subsystem and its various manager tasks.
show subscriber full username user_name |grep -i nat
Clearing Statistics and Counters
It may be necessary to periodically clear statistics and counters in order to gather new information. The system provides the ability to clear statistics and counters based on their grouping (PPP, MIPHA, MIPFA, etc.).
Statistics and counters can be cleared using the CLI clear command. Refer to the Command Line Reference for detailed information on using this command.
 
 
Appendix A
Direct Tunnel
 
This chapter briefly describes the 3G/4G UMTS direct tunnel (DT) feature, indicates how it is implemented on various systems on a per call basis, and provides feature configuration procedures.
Products supporting direct tunnel include:
Important: Direct tunnel is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
The SGSN determines if setup of a direct tunnel is allowed or disallowed. Currently, the SGSN and S-GW are the only products that provide configuration commands for this feature. All other products that support direct tunnel do so by default.
This chapter provides the following information:
Direct Tunnel Feature Overview
The direct tunnel architecture allows the establishment of a direct user plane (GTP-U) tunnel between the radio access network equipment (RNC) and the GGSN/P-GW.
Once a direct tunnel is established, the SGSN/S-GW continues to handle the control plane (RANAP/GTP-C) signaling and retains the responsibility of making the decision to establish direct tunnel at PDN context activation.
GTP-U Direct Tunneling
A direct tunnel improves the user experience (for example, expedites web page delivery, reduces round trip delay for conversational services) by eliminating switching latency from the user plane. An additional advantage, direct tunnel functionality implements optimization to improve the usage of user plane resources (and hardware) by removing the requirement from the SGSN/S-GW to handle the user plane processing.
A direct tunnel is achieved upon PDN context activation in the following ways:
3G network: The SGSN establishes a user plane (GTP-U) tunnel directly between the RNC and the GGSN, using an Updated PDN Context Request toward the GGSN.
Direct Tunneling - 3G Network
LTE network: When Gn/Gp interworking with pre-release 8 (3GPP) SGSNs is enabled, the GGSN service on the P-GW supports direct tunnel functionality. The SGSN establishes a user plane (GTP-U) tunnel directly between the RNC and the GGSN/P-GW, using an Update PDN Context Request toward the GGSN/P-GW.
Direct Tunneling - LTE Network, GTP-U Tunnel
LTE network: The SGSN establishes a user plane tunnel (GTP-U tunnel over an S12 interface) directly between the RNC and the S-GW, using an Update PDN Context Request toward the S-GW.
Direct Tunneling - LTE Network, S12 Interface
A major consequence of deploying a direct tunnel is that it produces a significant increase in control plane load on both the SGSN/S-GW and GGSN/P-GW components of the packet core. Hence, deployment requires highly scalable GGSNs/P-GWs since the volume and frequency of Update PDP Context messages to the GGSN/P-GW will increase substantially. The SGSN/S-GW platform capabilities ensure control plane capacity will not be a limiting factor with direct tunnel deployment.
The following figure illustrates the logic used within the SGSN/S-GW to determine if a direct tunnel will be setup.
Direct Tunneling - Establishment Logic
Direct Tunnel Configuration
The following configurations are provided in this section:
Configuring Direct Tunnel Support on the SGSN
By default, direct tunnel support is
disallowed on the SGSN/S-GW
allowed on the GGSN/P-GW.
The SGSN/S-GW direct tunnel functionality is enabled within an operator policy configuration. One aspect of an operator policy is to allow or disallow the setup of direct GTP-U tunnels. If no operator policies are configured, the system looks at the settings in the system operator policy named default.
For more information about operator policies and configuration details, refer to the Operator Policy chapter also in this guide.
Important: If direct tunnel is allowed in the default operator policy, then any incoming call that does not have an applicable operator policy configured will have direct tunnel allowed.
The following is a high-level view of the steps, and the associated configuration examples, to configure the SGSN to setup a direct tunnel.
Before beginning any of the following procedures, you must have completed (1) the basic service configuration for the SGSN, as described in the Cisco ASR Serving GPRS Support Node Administration Guide, and (2) the creation and configuration of a valid operator policy, as described in the Operator Policy chapter in this guide.
Step 1
Step 2
Important: It is only necessary to complete either step 2 or step 3 as a direct tunnel can not be setup on the basis of call filtering matched with both an APN profile and an IIMEI profile.
Step 3
Step 4
Step 5
(Optional) Configure the SGSN to disallow direct tunnel setup to a single GGSN that has been configured to allow it in the APN profile. This command allows the operator to restrict use of a GGSN for any reason, such as load balancing. Refer to the direct-tunnel-disabled-ggsn command in the SGTP Service Configuration Mode chapter of the Command Line Interface Reference.
Step 6
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Step 7
Check that your configuration changes have been saved by using the sample configuration found in the Verifying the SGSN Direct Tunnel Configuration section in this chapter.
Enabling Setup of GTP-U Direct Tunnels
The SGSN determines whether a direct tunnel can be setup and by default the SGSN doesn’t support direct tunnel.
Example Configuration
Enabling direct tunnel setup on an SGSN is done by configuring direct tunnel support in a call-control profile.
config
      call-control-profile <policy_name>
         direct-tunnel attempt-when-permitted
         end
Notes:
Enabling Direct Tunnel per APN
In each operator policy, APN profiles are configured to connect to one or more GGSNs and to control the direct tunnel access to that GGSN based on call filtering by APN. Multiple APN profiles can be configured per operator policy.
By default, APN-based direct tunnel functionality is allowed so any existing direct tunnel configuration must be removed to return to default and to ensure that the setup has not been restricted.
Example Configuration
The following is an example of the commands used to ensure that direct tunneling, to a GGSN(s) identified in the APN profile, is enabled:
config
   apn-profile <profile_name>
      remove direct tunnel
      end
Notes:
Enabling Direct Tunnel per IMEI
Some operator policy filtering of calls is done on the basis of international mobile equipment identity (IMEI) so the direct tunnel setup may rely upon the feature configuration in the IMEI profile.
The IMEI profile basis its permissions for direct tunnel on the RNC configuration associated with the IuPS service.
By default, direct tunnel functionality is enabled for all RNCs.
Example Configuration
The following is an example of the commands used to enable direct tunneling in the IMEI profile:
config
   imei-profile <profile_name>
      direct-tunnel check-iups-service
      end
Notes:
Enabling Direct Tunnel to Specific RNCs
SGSN access to radio access controllers (RNCs) is configured in the IuPS service.
Each IuPS service can include multiple RNC configurations that determine communications and features depending on the RNC.
By default, direct tunnel functionality is enabled for all RNCs.
Example Configuration
The following is an example of the commands used to ensure that restrictive configuration is removed and direct tunnel for the RNC is enabled:
config
   context <ctx_name>
      iups-service <service_name>
         rnc id <rnc_id>
            default direct-tunnel
            end
Notes:
Verifying the SGSN Direct Tunnel Configuration
Enabling the setup of a GTP-U direct tunnel on the SGSN is not a straight forward task. It is controlled by an operator policy with related configuration in multiple components. Each of these component configurations must be checked to ensure that the direct tunnel configuration has been completed. You need to begin with the operator policy itself.
Verifying the Operator Policy Configuration
For the feature to be enabled, it must be allowed in the call-control profile and the call-control profile must be associated with an operator policy. As well, either an APN profile or an IMEI profile must have been created/configured and associated with the same operator policy. Use the following command to display and verify the operator policy and the association of the required profiles:
show operator-policy full name <policy_name>
The output of this command displays profiles associated with the operator policy.
[local]asr5x00# show operator-policy full name oppolicy1
Operator Policy Name = oppolicy1
Call Control Profile Name                                 : ccprofile1
Validity                                                 : Valid
IMEI Range 99999999999990 to 99999999999995
IMEI Profile Name                                        : imeiprofile1
Validity                                               : Invalid
APN NI homers1
APN Profile Name                                             : apnprofile1
Validity                                               : Valid
APN NI visitors2
APN Profile Name                                             : apnprofile2
Validity                                                 : Invalid
Notes:
Verifying the Call-Control Profile Configuration
Use the following command to display and verify the direct tunnel configuration for the call-control profiles:
show call-control-profile full name <profile_name>
The output of this command displays all of the configuration, including direct tunnel for the specified call-control profile.
Call Control Profile Name = ccprofile1
...
Re-Authentication                                         : Disabled
Direct Tunnel                                             : Not Restricted
GTPU Fast Path                                            : Disabled
..
Verifying the APN Profile Configuration
Use the following command to display and verify the direct tunnel configuration in the APN profile:
show apn-profile full name <profile_name>
The output of this command displays all of the configuration, including direct tunnel for the specified APN profile.
Call Control Profile Name = apnprofile1
...
IP Source Validation                                      : Disabled
Direct Tunnel                                             : Not Restricted
Service Restriction for Access Type > UMTS                : Disabled
..
Verifying the IMEI Profile Configuration
Use the following command to display and verify the direct tunnel configuration in the IMEI profile:
show imei-profile full name <profile_name>
The output of this command displays all of the configuration, including direct tunnel for the specified IMEI profile.
IMEI Profile Name = imeiprofile1
Black List                                             : Disabled
GGSN Selection                                          : Disabled
Direct Tunnel                                           : Enabled
Verifying the RNC Configuration
Use the following command to display and verify the direct tunnel configuration in the RNC configuration:
show iups-service name <service_name>
The output of this command displays all of the configuration, including direct tunnel for the specified IuPS service.
IService name                        : iups1
...
Available RNC:
  Rnc-Id                             : 1
  Direct Tunnel                      : Not Restricted
Configuring S12 Direct Tunnel Support on the S-GW
The example in this section configures an S12 interface supporting direct tunnel bypass of the S4 SGSN for inter-RAT handovers.
The direct tunnel capability on the S-GW is enabled by configuring an S12 interface. The S4 SGSN is then responsible for creating the direct tunnel by sending an FTEID in a control message to the MME over the S3 interface. The MME forwards the FTEID to the S-GW over the S11 interfaces. The S-GW responds with it’s own U-FTEID providing the SGSN with the identification information required to set up the direct tunnel over the S12 interface.
Use the following example to configure this feature:
configure
   context <egress_context_name> -noconfirm
      interface <s12_interface_name>
         ip address <s12_ipv4_address_primary>
         ip address <s12_ipv4_address_secondary>
         exit
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <s12_interface_name> <egress_context_name>
      exit
   context <egress_context_name> -noconfirm
      gtpu-service <s12_gtpu_egress_service_name>
         bind ipv4-address <s12_interface_ip_address>
         exit
      egtp-service <s12_egtp_egress_service_name>
         interface-type interface-sgw-egress
         validation-mode default
         associate gtpu-service <s12_gtpu_egress_service_name>
         gtpc bind address <s12_interface_ip_address>
         exit
      sgw-service <sgw_service_name> -noconfirm
         associate egress-proto gtp egress-context <egress_context_name> egtp-service <s12_egtp_egress_service_name>
         end
Notes:
 
 
Appendix B
GRE Protocol Interface
 
This chapter provides information on Generic Routing Encapsulation protocol interface support in the GGSN or P-GW service node. The product Administration Guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in the respective product Administration Guide, before using the procedures in this chapter.
Important: GRE protocol interface support is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
This chapter discusses following topics for GRE protocol interface support:
Introduction
GRE protocol functionality adds one additional protocol on Cisco’s multimedia core platforms (ASR 5000 or higher) to support mobile users to connect to their enterprise networks through Generic Routing Encapsulation (GRE).
GRE tunnels can be used by the enterprise customers of a carrier 1) To transport AAA packets corresponding to an APN over a GRE tunnel to the corporate AAA servers and, 2) To transport the enterprise subscriber packets over the GRE tunnel to the corporation gateway.
The corporate servers may have private IP addresses and hence the addresses belonging to different enterprises may be overlapping. Each enterprise needs to be in a unique virtual routing domain, known as VRF. To differentiate the tunnels between same set of local and remote ends, GRE Key will be used as a differentiator.
It is a common technique to enable multi-protocol local networks over a single-protocol backbone, to connect non-contiguous networks and allow virtual private networks across WANs. This mechanism encapsulates data packets from one protocol inside a different protocol and transports the data packets unchanged across a foreign network. It is important to note that GRE tunneling does not provide security to the encapsulated protocol, as there is no encryption involved (like IPSEC offers, for example).
GRE Tunneling consists of three main components:
The most simplified form of the deployment scenario is shown in the following figure, in which GGSN has two APNs talking to two corporate networks over GRE tunnels.
GRE Interface Deployment Scenario
Supported Standards
Support for the following standards and requests for comments (RFCs) have been added with this interface support:
Supported Networks and Platforms
This feature supports all systems with StarOS Release 9.0 or later running GGSN and/or SGSN service for the core network services. The P-GW service supports this feature with StarOS Release 12.0 or later.
Licenses
GRE protocol interface support is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
Services and Application on GRE Interface
GRE interface implementation provides the following functionality with GRE protocol support.
How GRE Interface Support Works
The GRE interface provides two types of data processing; one for ingress packets and another for egress packets.
Ingress Packet Processing on GRE Interface
Figure given below provides a flow of process for incoming packets on GRE interface.
Note that in case the received packet is a GRE keep-alive or a ping packet then the outer IPV4 and GRE header are not stripped off (or get reattached), but instead the packet is forwarded as is to the VPN manager or kernel respectively. In case of all other GRE tunneled packets the IPV4 and GRE header are stripped off before sending the packet for a new flow lookup.
Ingress Packet Processing on GRE Interface
Egress Packet Processing on GRE Interface
Figure given below provides a flow of process for outgoing packets on GRE interface:
Egress Packet Processing on GRE Interface
GRE Interface Configuration
This section provides a high-level series of steps and the associated configuration examples for configuring the system with GRE interface in GGSN or P-GW services.
Important: This section provides the minimum instruction set to enable the GRE Protocol Interface support functionality on a GGSN or P-GW. Commands that configure additional functions for this feature are provided in the Command Line Interface Reference.
These instructions assume that you have already configured the system level configuration as described in System Administration Guide and specific product Administration Guide.
To configure the system to support GRE tunnel interface:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Step 8
Virtual Routing And Forwarding (VRF) Configuration
This section provides the configuration example to configure the VRF in a context:
configure
  context <vpn_context_name> -noconfirm ]
    ip vrf <vrf_name>
      ip maximum-routes <max_routes>
      end
Notes:
<vpn_context_name> is the name of the system context you want to use for VRF. For more information, refer System Administration Guide.
<vrf_name> is name of the VRF which is to be associated with various interfaces.
A maximum of 10000 routes can be configured through ip maximum-routes <max_routes> command.
GRE Tunnel Interface Configuration
This section provides the configuration example to configure the GRE tunnel interface and associate a VRF with GRE interface:
configure
  context <vpn_context_name>
    ip interface <intfc_name> tunnel
      ip vrf forwarding <vrf_name>
        ip address <internal_ip_address/mask>
        tunnel-mode gre
        source interface <non_tunn_intfc_to_corp>
        destination address <global_ip_address>
        keepalive interval <value> num-retry <retry>
        end
Notes:
<vpn_context_name> is the name of the system context you want to use for GRE interface configuration. For more information, refer Command Line Interface Reference.
<intfc_name> is name of the IP interface which is defined as a tunnel type interface and to be used for GRE tunnel interface.
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
<internal_ip_address/mask> is the network IP address with sub-net mask to be used for VRF forwarding.
<non_tunn_intfc_to_corp> is the name a non-tunnel interface which is required by system as source interface and preconfigured. For more information on interface configuration refer System Administration Guide.
<global_ip_address> is a globally reachable IP address to be used as a destination address.
Enabling OSPF for VRF
This section provides the configuration example to enable the OSPF for VRF to support GRE tunnel interface:
configure
  context <vpn_context_name>
    router ospf
      ip vrf <vrf_name>
      network <internal_ip_address/mask>
      end
Notes:
<vpn_context_name> is the name of the system context you want to use for OSPF routing. For more information, refer Routing in this guide.
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
<internal_ip_address/mask> is the network IP address with sub-net mask to be used for OSPF routing.
Associating IP Pool and AAA Group with VRF
This section provides the configuration example for associating IP pool and AAA groups with VRF:
configure
  context <vpn_context_name>
    ip pool <ip_pool_name> <internal_ip_address/mask> vrf <vrf_name>
      exit
    aaa group <aaa_server_group>
      ip vrf <vrf_name>
      end
Notes:
<vpn_context_name> is the name of the system context you want to use for IP pool and AAA server group.
<ip_pool_name> is name of a preconfigured IP pool. For more information refer System Administration Guide.
<aaa_server_group> is name of a preconfigured AAA server group. For more information refer AAA Interface Administrtion and Reference.
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
<internal_ip_address/mask> is the network IP address with sub-net mask to be used for IP pool.
Associating APN with VRF
This section provides the configuration example for associating an APN with VRF through AAA group and IP pool:
configure
  context <vpn_context_name>
    apn <apn_name>
      aaa group <aaa_server_group>
      ip address pool name <ip_pool_name>
      end
Notes:
<vpn_context_name> is the name of the system context you want to use for APN configuration.
<ip_pool_name> is name of a preconfigured IP pool. For more information refer System Administration Guide.
<aaa_server_group> is name of a preconfigured AAA server group. For more information refer AAA Interface Administrtion and Reference.
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
Static Route Configuration
This section provides the optional configuration example for configuring static routes when the route to the server is not learnt from the corporate over OSPFv2:
configure
  context <vpn_context_name>
    ip route <internal_ip_address/mask> tunnel <tunnel_intfc_name> vrf <vrf_name>
      end
Notes:
<vpn_context_name> is the name of the system context you want to use for static route configuration.
<internal_ip_address/mask> is the network IP address with sub-net mask to be used as static route.
<tunnel_intfc_name> is name of a predefined tunnel type IP interface which is to be used for GRE tunnel interface.
<vrf_name> is the name of the VRF which is preconfigured in context configuration mode.
Verifying Your Configuration
This section explains how to display and review the configurations after saving them in a .cfg file as described in the System Administration Guide and also to retrieve errors and warnings within an active configuration for a service.
Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.
These instructions are used to verify the GRE interface configuration.
Step 1
show ip interface
The output of this command displays the configuration of the all interfaces configured in a context.
Intf Name:       foo1
Intf Type:       Broadcast
Description:
IP State:        UP (Bound to 17/2 untagged, ifIndex 285343745)
IP Address:      1.1.1.1              Subnet Mask:     255.255.255.0
Bcast Address:   1.1.1.255            MTU:             1500
Resoln Type:     ARP                  ARP timeout:     60 secs
L3 monitor LC-port switchover: Disabled
Number of Secondary Addresses: 0
Intf Name:       foo2
Intf Type:       Tunnel (GRE)
Description:
VRF:             vrf-tun
IP State:        UP (Bound to local address 1.1.1.1 (foo1), remote address 5.5.5.5)
IP Address:      10.1.1.1             Subnet Mask:     255.255.255.0
Intf Name:       foo3
Intf Type:       Tunnel (GRE)
Description:
IP State:        DOWN (<state explaining the reason of being down>)
IP Address:      20.20.20.1             Subnet Mask:     255.255.255.0
Step 2
show ip interface gre-keepalive
The output of this command displays the configuration of the keepalive for GRE interface configured in a context.
 
 
Appendix C
Gx Interface Support
 
This chapter provides information on configuring Gx interface to support policy and charging control for subscribers.
The IMS service provides application support for transport of voice, video, and data independent of access support. Roaming IMS subscribers require apart from other functionality sufficient, uninterrupted, consistent, and seamless user experience during an application session. It is also important that a subscriber gets charged only for the resources consumed by the particular IMS application used.
It is recommended that before using the procedures in this chapter you select the configuration example that best meets your service model, and configure the required elements for that model as described in this Administration Guide.
The following topics are covered in this chapter:
Rel. 6 Gx Interface
Rel. 6 Gx interface support is available on the Cisco ASR chassis running StarOS 8.0 and later releases for the following products:
This section describes the following topics:
Introduction
In GPRS/UMTS networks, the client functionality lies with the GGSN/IPSG, therefore in the IMS authorization scenario it is also called Access Gateway (AGW).
The provisioning of charging rules that are based on the dynamic analysis of flows used for the IMS session is carried out over the Gx interface. In 3GPP, Rel. 6 the Gx is an interface between Access Gateway functioning as Traffic Plane Function (TPF) and the Charging Rule Function (CRF). It is based on the Diameter Base Protocol (DIABASE) and the Diameter Credit Control Application (DCCA) standard. The GGSN/TPF acts as the client where as the CRF contains the Diameter server functionality.
The AGW is required to perform query, in reply to which the servers provision certain policy or rules that are enforced at the AGW for that particular subscriber session. The CRF analyzes the IP flow data, which in turn has been retrieved from the Session Description Protocol (SDP) data exchanged during IMS session establishment.
Important: In addition to standard Gx interface functionality, the Gx interface implemented here provides support of SBLP with additional AVPs in custom DPCA dictionaries. For more information on customer-specific support contact your local technical support representative. In view of required flow bandwidth and QoS, the system provides enhanced support for use of Service Based Local Policy (SBLP) to provision and control the resources used by the IMS subscriber. SBLP is based on the dynamic parameters such as the media/traffic flows for data transport, network conditions and static parameters, such as subscriber configuration and category. It also provides Flow-based Charging (FBC) mechanism to charge the subscriber dynamically based on content usage. With this additional functionality, the Cisco Systems Gateway can act as an Enhanced Policy Decision Function (E-PDF).
Supported Networks and Platforms
This feature is supported on all chassis with StarOS Release 8.0 or later running GGSN service for the core network services.
License Requirements
The Rel. 6 Gx interface support is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
 
Supported Standards
The Rel 6. Gx interface support is based on the following standards and request for comments (RFCs):
In addition to the above RFCs and standards, IMS Authorization partially supports 3GPP TS 29.212 for Policy and Charging Control over Gx reference point functionality.
How it Works
This section describes the IMS authorization and dynamic policy support in GPRS/UMTS networks.
The following figure and table explain the IMS authorization process between a system and IMS components that is initiated by the MN.
In the case of GGSN, the DPCA is the Gx interface to the Control and Charging Rule Function (CRF). In this context CRF will act as Enhanced Policy Decision Function (E-PDF). The CRF may reside in Proxy-Call Session Control Function (P-CSCF) or on stand-alone system.
The interface between IMSA with CRF is the Gx interface, and between Session Manager and Online Charging Service (OCS) is the Gy interface.
Note that the IMS Authorization (IMSA) service and Diameter Policy Control Application (DPCA) are part of Session Manager on the system, and separated in the following figure for illustration purpose only.
Rel. 6 Gx IMS Authorization Call Flow
Rel. 6 Gx IMS Authorization Call flow Description
Configuring Rel. 6 Gx Interface
To configure Rel. 6 Gx interface functionality:
Step 1
Step 2
Step 3
Step 4
Step 5
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
Configuring IMS Authorization Service at Context Level
Use the following example to configure IMS Authorization Service at context level for IMS subscribers in GPRS/UMTS networks:
configure
  context <context_name>
     ims-auth-service <imsa_service_name>
        p-cscf table { 1 | 2 } row-precedence <precedence_value> { address <ip_address> | ipv6-address <ipv6_address> }
        p-cscf discovery { table { 1 | 2 } [ algorithm { ip-address-modulus | msisdn-modulus | round-robin } ] | diameter-configured }
        policy-control
           diameter origin endpoint <endpoint_name>
           diameter dictionary <dictionary>
           failure-handling cc-request-type { any-request | initial-request | terminate-request | update-request } { diameter-result-code { any-error | <result_code> [ to <end_result_code> ] } } { continue | retry-and-terminate | terminate }
           diameter host-select row-precedence <precedence_value> table { 1 | 2 } host <host_name> [ realm <realm_name> ] [ secondary host <host_name> [ realm <realm_name> ] ]
           diameter host-select reselect subscriber-limit <subscriber_limit> time-interval <duration>
           diameter host-select table { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin }
           end
Notes:
<context_name> must be the name of the context where you want to enable IMS Authorization Service.
<imsa_service_name> must be the name of the IMS Authorization Service to be configured for the Gx interface authentication.
Secondary P-CSCF IP address can be configured in the P-CSCF table. Refer to the Command Line Interface Reference for more information on the p-cscf table command.
Optional: To configure the quality of service (QoS) update timeout for a subscriber, in the IMS Authorization Service Configuration Mode, enter the following command:
qos-update-timeout <timeout_duration>
Optional: To configure signalling restrictions, in the IMS Authorization Service Configuration Mode, enter the following commands:
signaling-flag { deny | permit }
signaling-flow permit server-address <ip_address> [ server-port { <port_number> | range <start_number> to <end_number> } ] [ description <string> ]
Optional: To configure action on packets that do not match any policy gates in the general purpose PDP context, in the IMS Authorization Service Configuration Mode, enter the following command:
traffic-policy general-pdp-context no-matching-gates direction { downlink | uplink } { forward | discard }
Optional: To configure the algorithm to select Diameter host table, in the Policy Control Configuration Mode, enter the following command:
diameter host-select table { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin }
Verifying IMS Authorization Service Configuration
To verify the IMS Authorization Service configuration:
Step 1
context <context_name>
Step 2
show ims-authorization service name <imsa_service_name>
Applying IMS Authorization Service to an APN
After configuring IMS Authorization service at the context-level, an APN within the same context must be configured to use the IMS Authorization service for an IMS subscriber.
Use the following example to apply IMS Authorization service functionality to a previously configured APN within the context configured in the Configuring IMS Authorization Service section.
configure
  context <context_name>
     apn <apn_name>
        ims-auth-service <imsa_service_name>
        end
Notes:
<context_name> must be the name of the context in which the IMS Authorization service was configured.
<imsa_service_name> must be the name of the IMS Authorization Service configured for IMS authentication in the context.
Verifying Subscriber Configuration
Verify the IMS Authorization Service configuration for subscriber(s) by entering the following command:
show subscribers ims-auth-service <imsa_service_name>
<imsa_service_name> must be the name of the IMS Authorization Service configured for IMS authentication.
Rel. 7 Gx Interface
Rel. 7 Gx interface support is available on the Cisco ASR chassis running StarOS 8.1 or StarOS 9.0 and later releases for the following products:
This section describes the following topics:
Introduction
For IMS deployment in GPRS/UMTS networks the system uses Rel. 7 Gx interface for policy-based admission control support and flow-based charging. The Rel. 7 Gx interface supports enforcing policy control features like gating, bandwidth limiting, and so on, and also supports flow-based charging. This is accomplished via dynamically provisioned Policy Control and Charging (PCC) rules. These PCC rules are used to identify Service Data Flows (SDF) and do charging. Other parameters associated with the rules are used to enforce policy control.
The PCC architecture allows operators to perform service-based QoS policy, and flow-based charging control. In the PCC architecture, this is accomplished mainly by the Policy and Charging Enforcement Function (PCEF)/Cisco Systems GGSN and the Policy and Charging Rules Function (PCRF).
In GPRS/UMTS networks, the client functionality lies with the GGSN, therefore in the IMS authorization scenario it is also called the Gateway. In the following figure, Gateway is the Cisco Systems GGSN, and the PCEF function is provided by Enhanced Charging Service (ECS). The Rel 7. Gx interface is implemented as a Diameter connection. The Gx messages mostly involve installing/modifying/removing dynamic rules and activating/deactivating predefined rules.
The Rel. 7 Gx reference point is located between the Gateway and the PCRF. This reference point is used for provisioning and removal of PCC rules from the PCRF to the Gateway, and the transmission of traffic plane events from the Gateway to the PCRF. The Gx reference point can be used for charging control, policy control, or both by applying AVPs relevant to the application. The following figure shows the reference points between various elements involved in the policy and charging architecture.
PCC Logical Architecture
Within the Gateway, the IMSA and DPCA modules handle the Gx protocol related functions (at the SessMgr) and the policy enforcement and charging happens at ECS. The Gy protocol related functions are handled within the DCCA module (at the ECS). The following figure shows the interaction between components within the Gateway.
PCC Architecture within Cisco PCEF
Supported Networks and Platforms
This feature is supported on all chassis with StarOS Release 8.1 and later running GGSN service for the core network services.
License Requirements
The Rel. 7 Gx interface support is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
 
Supported Standards
The Rel 7. Gx interface support is based on the following standards and RFCs:
Terminology and Definitions
This section describes features and terminology pertaining to Rel. 7 Gx functionality.
Policy Control
The process whereby the PCRF indicates to the PCEF how to control the IP-CAN bearer.
Policy control comprises the following functions:
Binding: Binding is the generation of an association between a Service Data Flow (SDF) and the IP CAN bearer (for GPRS a PDP context) transporting that SDF.
The QoS demand in the PCC rule, as well as the SDF template are input for the bearer binding. The selected bearer will have the same QoS Class as the one indicated by the PCC rule.
Depending on the type of IP-CAN and bearer control mode, bearer binding can be executed either by the PCRF, or both PCRF and PCEF.
Gating Control: Gating control is the blocking or allowing of packets, belonging to an SDF, to pass through to the desired endpoint. A gate is described within a PCC rule and gating control is applied on a per SDF basis. The commands to open or close the gate leads to the enabling or disabling of the passage for corresponding IP packets. If the gate is closed, all packets of the related IP flows are dropped. If the gate is opened, the packets of the related IP flows are allowed to be forwarded.
Event Reporting: Event reporting is the notification of and reaction to application events to trigger new behavior in the user plane as well as the reporting of events related to the resources in the Gateway (PCEF).
Note that in 11.0 and later releases, RAR with unknown event triggers are silently ignored and responded with DIAMETER_SUCCESS. In earlier releases, when unknown event triggers were received in the RAR command from PCRF, invalid AVP result code was set in the RAA command.
Important: In this release, event triggers “IP-CAN_CHANGE” and “MAX_NR_BEARERS_REACHED” are not supported.
QoS Control: QoS control is the authorization and enforcement of the maximum QoS that is authorized for a SDF or an IP-CAN bearer or a QoS Class Identifier (QCI). In case of an aggregation of multiple SDFs (for GPRS a PDP context), the combination of the authorized QoS information of the individual SDFs is provided as the authorized QoS for this aggregate.
Important: In this release, QoS Resource Reservation is not supported.
Supported Features:
Important: In this release, coordination of authorized QoS scopes in mixed mode (BCM = UE_NW) is not supported.
If the Bearer-Control-Mode AVP is not received from PCRF, the IP-CAN session is not terminated. The value negotiated between UE/SGSN/GGSN is considered as the BCM. The following values are considered for each of the service types:
In the following scenarios UE_ONLY is chosen as the BCM:
Scenario 1:
Scenario 2:
If the installation/activation of one or more new PCC rules (that is, rules that were not previously successfully installed) fails, the PCEF sets the PCC-Rule-Status to INACTIVE for both the PUSH and the PULL modes.
If a PCC rule was successfully installed/activated, but can no longer be enforced by the PCEF, the PCEF shall send the PCRF a new CCR command and include a Charging-Rule-Report AVP. The PCEF shall include the Rule-Failure-Code AVP within the Charging-Rule-Report AVP and shall set the PCC-Rule-Status to INACTIVE.
Important: In 11.0 and later releases, Rule-Activation-Time / Rule-Deactivation-Time / Revalidation-Time AVP is successfully parsed only if its value corresponds to current time or a later time than the current IPSG time, else the AVP and entire message is rejected. In earlier releases the AVP is successfully parsed only if its value corresponds to a later time than the current IPSG time, else the AVP and entire message is rejected.
Charging Control
Charging Control is the process of associating packets belonging to a SDF to a charging key, and applying online charging and/or offline charging, as appropriate. Flow-based charging handles differentiated charging of the bearer usage based on real time analysis of the SDFs. In order to allow for charging control, the information in the PCC rule identifies the SDF and specifies the parameters for charging control. The PCC rule information may depend on subscription data.
In the case of online charging, it is possible to apply an online charging action upon PCEF events (for example, re-authorization upon QoS change).
It is possible to indicate to the PCEF that interactions with the charging systems are not required for a PCC rule, that is to perform neither accounting nor credit control for this SDF, and then no offline charging information is generated.
Supported Features:
Important: In this release, provisioning of primary or secondary charging collection function name (Offline Charging Server (OFCS) addresses) over Gx is not supported.
Charging Correlation
For the purpose of charging correlation between SDF level and application level (for example, IMS) as well as on-line charging support at the application level, applicable charging identifiers and IP-CAN type identifiers are passed from the PCRF to the AF, if such identifiers are available.
For IMS bearer charging, the IP Multimedia Core Network (IM CN) subsystem and the Packet Switched (PS) domain entities are required to generate correlated charging data.
In order to achieve this, the Gateway provides the GGSN Charging Identifier (GCID) associated with the PDP context along with its address to the PCRF. The PCRF in turn sends the IMS Charging Identifier (ICID), which is provided by the P-CSCF, to the Gateway. The Gateway generates the charging records including the GCID as well as the ICID if received from PCRF, so that the correlation of charging data can be done with the billing system.
PCRF also provides the flow identifier, which uniquely identifies an IP flow in an IMS session.
Policy and Charging Control (PCC) Rules
A PCC rule enables the detection of an SDF and provides parameters for policy control and/or charging control. The purpose of the PCC rule is to:
The PCEF selects a PCC rule for each packet received by evaluating received packets against SDF filters of PCC rules in the order of precedence of the PCC rules. When a packet matches a SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied.
There are two types of PCC rules:
Important: A third type of rule, the static PCC rule can be preconfigured in the chassis by the operators. Static PCC rules are not explicitly known in the PCRF, and are not under control of the PCRF. Static PCC rules are bound to general purpose bearer with no Gx control.
A PCC rule consists of:
Important: In earlier releases, ECS used only the Priority-Level part of ARP byte for bearer binding, (along with QCI). Now the entire ARP byte is used for bearer binding (along with QCI). Since the capability and vulnerability bits are optional in a dynamic rule, if a dynamic rule is received without these flags, it is assumed that the capability bit is set to 1 (disabled) and vulnerability bit is set to 0 (enabled). For predefined rules, currently configuring these two flags is not supported, so as of now all predefined rules are assumed to have capability bit set to 1 (disabled) and vulnerability bit set to 0 (enabled).
Important: In this release, configuring the Metering Method and Reporting Level for dynamic PCC rules is not supported.
PCC rules also include Application Function (AF) record information for enabling charging correlation between the application and bearer layer if the AF has provided this information via the Rx interface. For IMS, this includes the IMS Charging Identifier (ICID) and flow identifiers.
PCC Procedures over Gx Reference Point
Request for PCC rules
The PCEF, via the Gx reference point, requests for PCC rules in the following instances:
PCC rules can also be requested as a consequence of a failure in the PCC rule installation/activation or enforcement without requiring an event trigger.
Provisioning of PCC rules
The PCRF indicates, via the Rel. 7 Gx reference point, the PCC rules to be applied at the PCEF. This may be using one of the following procedures:
For each request from the PCEF or upon unsolicited provision the PCRF provisions zero or more PCC rules. The PCRF may perform an operation on a single PCC rule by one of the following means:
Important: In 11.0 and later releases, the maximum valid length for a charging rule name is 63 bytes. When the length of the charging rule name is greater than 63 bytes, a charging rule report with RESOURCES_LIMITATION as Rule-Failure-Code is sent. This charging rule report is sent only when the length of the rule name is lesser than 128 characters. When the charging rule name length is greater than or equal to 128 characters no charging rule report will be sent. In earlier releases, the length of the charging rule name constructed by PCRF was limited to 32 bytes.
Selecting a PCC Rule for Uplink IP Packets
If PCC is enabled, the PCEF selects the applicable PCC rule for each received uplink IP packet within an IP CAN bearer by evaluating the packet against uplink SDF filters of PCRF-provided or predefined active PCC rules of this IP CAN bearer in the order of the precedence of the PCC rules.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the uplink SDF filters of the PCRF-provided PCC rule is applied first.
Important: In 11.0 and later releases, IMSA and ECS allow the PCRF to install two (or more) dynamic rules with the same precedence value. In earlier releases, for two distinct dynamic rules having the same precedence the second rule used to be rejected.
When a packet matches an SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied. Uplink IP packets which do not match any PCC rule of the corresponding IP CAN bearer are discarded.
Selecting a PCC Rule and IP CAN Bearer for Downlink IP Packets
If PCC is enabled, the PCEF selects a PCC rule for each received downlink IP packet within an IP CAN session by evaluating the packet against downlink SDF filters of PCRF-provided or predefined active PCC rules of all IP CAN bearers of the IP CAN session in the order of the precedence of the PCC rules.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the downlink SDF filters of the PCRF-provided PCC rule are applied first.
When a packet matches a SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied. The Downlink IP Packet is transported within the IP CAN bearer where the selected PCC rule is mapped. Downlink IP packets that do not match any PCC rule of the IP CAN session are discarded.
The following procedures are also supported:
The PCEF applies IP CAN specific procedures to terminate the IP CAN session. For GPRS, the GGSN send a PDP context deactivation request with the teardown indicator set to indicate that the termination of the entire IP-CAN session is requested. Furthermore, the PCEF applies the “Indication of IP CAN Session Termination” procedure.
In 12.0 and later releases, volume or rule information obtained from PCRF is discarded if the subscriber is going down.
Volume Reporting Over Gx
This section describes the 3GPP Rel. 9 Volume Reporting over Gx feature, which is supported by all products supporting Rel. 7 Gx interface.
License Requirements
The Volume Reporting over Gx is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
Supported Standards
The Volume Reporting over Gx feature is based on the following standard:
3GPP TS 29.212 V9.3.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 9).
Feature Overview
The Volume Reporting over Gx feature provides PCRF the capability to make real-time decisions based on the data usage by subscribers.
Important: Volume Reporting over Gx is applicable only for volume quota.
Important: In release 10.0, only total data usage reporting is supported, uplink/downlink level reporting is not supported. In 10.2 and later releases, it is supported.
Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
Important: In 12.2 and later releases, usage reporting on bearer termination is supported.
The following steps explain how Volume Reporting over Gx works:
1.
2.
3.
4.
5.
6.
Usage Monitoring
In 12.0 and later releases, enabling and disabling session usage in a single message from PCRF is supported. This is supported only if the monitoring key is associated at session level.
In 12.0 and later releases, monitoring of usage based on input/output octet threshold levels is supported. Usage is reported based on the enabled threshold level. If multiple levels are enabled, usage will be reported on all the enabled levels even if only one of the levels is breached. Monitoring will be stopped on the missing threshold levels in the response for the usage report from PCRF (expected to provide the complete set again if PCRF wants to continue monitoring on the multiple levels enabled earlier).
Total threshold level along with UL/DL threshold level in the GSU AVP is treated as an error and only total threshold level is accepted.
Usage monitoring is supported for static, predefined rules, and dynamic rule definitions.
Usage Reporting
Usage at subscriber/flow level is reported to PCRF under the following conditions:
For session-level reporting, the actual usage volume is compared with the usage volume threshold.
For rule-level reporting the rule that hits the data traffic is used to find out if the monitoring key is associated with it, and based on the monitoring key the data usage is checked. Once the condition is met, it reports the usage information to IMSA and continues monitoring. IMSA then triggers the CCR-U if “USAGE_REPORT” trigger is enabled by the PCRF. The Usage-Monitoring-Information AVP is sent in this CCR with the “Used-Service-Unit” set to the amount of data usage by subscriber.
If PCRF does not provide a new usage threshold in the usage monitoring information as a result of CCR from PCEF when the usage threshold is reached, the usage monitoring is stopped at PCEF and no usage status is reported.
In the non-standard Volume Reporting over Gx implementation, usage monitoring will be stopped once the threshold is breached, else the monitoring will continue. There will be no further usage reporting until the CCA is received.
In the case of standard implementation, this must be enabled by CLI configuration.
Important: The Usage Reporting on Revalidation Timeout feature is available by default in non-standard implementation of Volume Reporting over Gx. In 10.2 and later releases, this is configurable in the standard implementation. This is not supported in 10.0 release for standard based volume reporting.
Once the usage is reported, the usage counter is reset to zero. The PCEF continues to track data usage from the zero value after the threshold is reached and before a new threshold is provided by the PCRF. If a new usage threshold is not provided by the PCRF in the acknowledgement of an IP-CAN Session modification where its usage was reported, then usage monitoring does not continue in the PCEF for that IP CAN session and and the usage accumulated between the CCR-CCA will be discarded.
For information on how to configure the Volume Reporting over Gx feature, see the Configuring Volume Reporting over Gx section.
How Rel. 7 Gx Works
This section describes how dynamic policy and charging control for subscribers works with Rel. 7 Gx interface support in GPRS/UMTS networks.
The following figure and table explain the IMSA process between a system and IMS components that is initiated by the UE.
In this example, the Diameter Policy Control Application (DPCA) is the Gx interface to the PCRF. The interface between IMSA with PCRF is the Gx interface, and the interface between Session Manager (SessMgr) and Online Charging Service (OCS) is the Gy interface. Note that the IMSA service and DPCA are part of SessMgr on the system and separated in the figure for illustration purpose only.
Rel. 7 Gx IMS Authorization Call Flow
Rel. 7 Gx IMS Authorization Call flow Description
Configuring Rel. 7 Gx Interface
To configure Rel. 7 Gx interface functionality, the IMS Authorization service must be configured at the context level, and then the APN configured to use the IMS Authorization service.
To configure Rel. 7 Gx interface functionality:
Step 1
Step 2
Step 3
Step 4
Step 5
Optional: Configure the Volume Reporting over Gx feature as described in the Configuring Volume Reporting over Gx section.
Step 6
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
Configuring IMS Authorization Service at Context Level
Use the following example to configure IMS Authorization service at context level for IMS subscribers in GPRS/UMTS networks:
configure
  context <context_name>
     ims-auth-service <imsa_service_name>
        p-cscf discovery table { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin }
        p-cscf table { 1 | 2 } row-precedence <precedence_value> { address <ip_address> | ipv6-address <ipv6_address> } [ secondary { address <ip_address> | ipv6-address <ipv6_address> } ]
        policy-control
           diameter origin endpoint <endpoint_name>
           diameter dictionary <dictionary>
           diameter request-timeout <timeout_duration>
           diameter host-select table { { { 1 | 2 } algorithm { ip-address-modulus | msisdn-modulus | round-robin } } | prefix-table { 1 | 2 } }
           diameter host-select row-precedence <precedence_value> table { { { 1 | 2 } host <host_name> [ realm <realm_id> ] [ secondary host <host_name> [ realm <realm_id> ] ] } | { prefix-table { 1 | 2 } msisdn-prefix-from <msisdn_prefix_from> msisdn-prefix-to <msisdn_prefix_to> host <host_name> [ realm <realm_id> ] [ secondary host <sec_host_name> [ realm <sec_realm_id> ] algorithm { active-standby | round-robin } ] } } [ -noconfirm ]
           diameter host-select reselect subscriber-limit <subscriber_limit> time-interval <duration>
           failure-handling cc-request-type { any-request | initial-request | terminate-request | update-request } { diameter-result-code { any-error | <result_code> [ to <end_result_code> ] } } { continue | retry-and-terminate | terminate }
           end
Notes:
<context_name> must be the name of the context where you want to enable IMS Authorization service.
<imsa_service_name> must be the name of the IMS Authorization service to be configured for Rel. 7 Gx interface authentication.
To enable the Gx interface to connect to a specific PCRF for a range of subscribers configure msisdn-prefix-from <msisdn_prefix_from> and msisdn-prefix-to <msisdn_prefix_to> with the starting and ending MSISDNs respectively.
To enable the Gx interface to connect to a specific PCRF for a specific subscriber, configure both msisdn-prefix-from <msisdn_prefix_from> and msisdn-prefix-to <msisdn_prefix_to> with the same MSISDN.
In StarOS 8.1 and later releases, per MSISDN prefix range table a maximum of 128 rows can be added. In StarOS 8.0 and earlier releases, a maximum of 100 rows can be added.
The MSISDN ranges must not overlap between rows.
Optional: To configure the Quality of Service (QoS) update timeout for a subscriber, in the IMS Authorization Service Configuration Mode, enter the following command:
qos-update-timeout <timeout_duration>
Optional: To configure signalling restrictions, in the IMS Authorization Service Configuration Mode, enter the following commands:
signaling-flag { deny | permit }
signaling-flow permit server-address <ip_address> [ server-port { <port_number> | range <start_number> to <end_number> } ] [ description <string> ]
Optional: To configure action on packets that do not match any policy gates in the general purpose PDP context, in the IMS Authorization Service Configuration Mode, enter the following command:
traffic-policy general-pdp-context no-matching-gates direction { downlink | uplink } { forward | discard }
To configure the GGSN/PCEF to use a pre-defined rule when the Gx fails, set the failure-handling cc-request-type CLI to continue. Policies available/in use will continue to be used and there will be no further interaction with the PCRF.
configure
  active-charging service <ecs_service_name>
     charging-action <charging_action_name>
        cca charging credit
        exit
configure
  active-charging service <ecs_service_name>
     rulebase <rulebase_name>
        billing-records rf
        exit
Verifying the Configuration
To verify the IMS Authorization service configuration:
Step 1
context <context_name>
Step 2
show ims-authorization service name <imsa_service_name>
Applying IMS Authorization Service to an APN
After configuring IMS Authorization service at the context-level, an APN within the same context must be configured to use the IMS Authorization service for an IMS subscriber.
Use the following example to apply IMS Authorization service functionality to a previously configured APN within the context configured in the Configuring Rel. 7 Gx Interface section.
configure
  context <context_name>
     apn <apn_name>
        ims-auth-service <imsa_service_name>
        active-charging rulebase <rulebase_name>
        end
Notes:
<context_name> must be the name of the context in which the IMS Authorization service was configured.
<imsa_service_name> must be the name of the IMS Authorization service configured for IMS authentication in the context.
policy-control charging-rule-base-name active-charging-group-of-ruledefs
Verifying Subscriber Configuration
Verify the IMS Authorization service configuration for subscriber(s) by entering the following command:
show subscribers ims-auth-service <imsa_service_name>
<imsa_service_name> must be the name of the IMS Authorization service configured for IMS authentication.
Configuring Volume Reporting over Gx
This section describes the configuration required to enable Volume Reporting over Gx.
To enable Volume Reporting over Gx, use the following configuration:
configure
  active-charging service <ecs_service_name>
     rulebase <rulebase_name>
        action priority <priority> dynamic-only ruledef <ruledef_name> charging-action <charging_action_name> monitoring-key <monitoring_key>
        exit
     exit
  context <context_name>
     ims-auth-service <imsa_service_name>
        policy-control
           event-update send-usage-report [ reset-usage ]
           end
Notes:
The event-update CLI which enables volume usage report to be sent in event updates is available only in 10.2 and later releases. The optional keyword reset-usage enables to support delta reporting wherein the usage is reported and reset at PCEF. If this option is not configured, the behavior is to send the usage information as part of event update but not reset at PCEF.
Gathering Statistics
This section explains how to gather Rel. 7 Gx statistics and configuration information.
In the following table, the first column lists what statistics to gather, and the second column lists the action to perform.
Gathering Rel. 7 Gx Statistics and Information
Rel. 8 Gx Interface
Rel. 8 Gx interface support is available on the Cisco ASR chassis running StarOS 10.0 or StarOS 11.0 and later releases.
This section describes the following topics:
HA/PDSN Rel. 8 Gx Interface Support
This section provides information on configuring Rel. 8 Gx interface for HA and PDSN to support policy and charging control for subscribers in CDMA networks.
The IMS service provides application support for transport of voice, video, and data independent of access support. Roaming IMS subscribers in CDMA networks require apart from other functionality sufficient, uninterrupted, consistent, and seamless user experience during an application session. It is also important that a subscriber gets charged only for the resources consumed by the particular IMS application used.
It is recommended that before using the procedures in this section you select the configuration example that best meets your service model, and configure the required elements for that model as described in this Administration Guide.
This section describes the following topics:
Introduction
For IMS deployment in CDMA networks the system uses Rel. 8 Gx interface for policy-based admission control support and flow-based charging (FBC). The Rel. 8 Gx interface supports enforcing policy control features like gating, bandwidth limiting, and so on, and also supports FBC. This is accomplished via dynamically provisioned Policy Control and Charging (PCC) rules. These PCC rules are used to identify Service Data Flows (SDF) and to do charging. Other parameters associated with the rules are used to enforce policy control.
The PCC architecture allows operators to perform service-based QoS policy and FBC control. In the PCC architecture, this is accomplished mainly by the Policy and Charging Enforcement Function (PCEF)/HA/PDSN and the Policy and Charging Rules Function (PCRF). The client functionality lies with the HA/PDSN, therefore in the IMS Authorization (IMSA) scenario it is also called the Gateway. The PCEF function is provided by the Enhanced Charging Service (ECS). The Gx interface is implemented as a Diameter connection. The Gx messaging mostly involves installing/modifying/removing dynamic rules and activating/deactivating predefined rules.
The Gx reference point is located between the Gateway/PCEF and the PCRF. This reference point is used for provisioning and removal of PCC rules from the PCRF to the Gateway/PCEF, and the transmission of traffic plane events from the Gateway/PCEF to the PCRF. The Gx reference point can be used for charging control, policy control, or both by applying AVPs relevant to the application.
The following figure shows the reference points between elements involved in the policy and charging architecture.
HA/PDSN Rel. 8 Gx PCC Logical Architecture
Within the Gateway, the IMSA and DPCA modules handle the Gx protocol related functions (at the SessMgr) and the policy enforcement and charging happens at ECS. The Gy protocol related functions are handled within the DCCA module (at the ECS).
The following figure shows the interaction between components within the Gateway.
HA/PDSN Rel. 8 Gx PCC Architecture within PCEF
License Requirements
The HA/PDSN Rel. 8 Gx interface support is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
Supported Standards
HA/PDSN Rel 8. Gx interface support is based on the following standards and RFCs:
Terminology and Definitions
This section describes features and terminology pertaining to HA/PDSN Rel. 8 Gx functionality.
Policy Control
The process whereby the PCRF indicates to the PCEF how to control the IP-CAN session.
Policy control comprises the following functions:
Binding
In the HA/PDSN Rel. 8 Gx implementation, since there are no bearers within a MIP session the IP-CAN Bearer concept does not apply. Only authorized IP-CAN session is applicable.
Gating Control
Gating control is the blocking or allowing of packets belonging to an SDF, to pass through to the desired endpoint. A gate is described within a PCC rule and gating control is applied on a per SDF basis. The commands to open or close the gate leads to the enabling or disabling of the passage for corresponding IP packets. If the gate is closed, all packets of the related IP flows are dropped. If the gate is open, the packets of the related IP flows are allowed to be forwarded.
Event Reporting
Important: Unconditional reporting of event triggers from PCRF to PCEF when PCEF has not requested for is not supported.
Important: In the HA/PDSN Rel. 8 Gx implementation, only the AN_GW_CHANGE (21) event trigger is supported.
Event reporting is the notification of and reaction to application events to trigger new behavior in the user plane as well as the reporting of events related to the resources in the Gateway (PCEF). Event triggers may be used to determine which IP-CAN session modification or specific event causes the PCEF to re-request PCC rules. Event trigger reporting from PCEF to PCRF, and provisioning of event triggers happens at IP-CAN session level.
The Event Reporting Function (ERF) located in the PCEF, receives event triggers from PCRF during the Provision of PCC Rules procedure and performs event trigger detection. When an event matching the received event trigger occurs, the ERF reports the occurred event to the PCRF. If the provided event triggers are associated with certain parameter values then the ERF includes those values in the response to the PCRF.
QoS Control
Important: In the HA/PDSN Rel. 8 Gx implementation, only authorized IP-CAN Session is supported. Provisioning of authorized QoS per IP-CAN bearer, policy enforcement for authorized QoS per QCI, and coordination of authorized QoS scopes in mixed mode are not applicable.
QoS control is the authorization and enforcement of the maximum QoS that is authorized for an SDF. In case of an aggregation of multiple SDFs, the combination of the authorized QoS information of the individual SDFs is provided as the authorized QoS for this aggregate. QoS control per SDF allows the PCC architecture to provide the PCEF with the authorized QoS to be enforced for each specific SDF.
QoS authorization information may be dynamically provisioned by the PCRF, or it can be a predefined PCC rule in the PCEF. For a predefined PCC rule within the PCEF, the authorized QoS information takes affect when the PCC rule is activated. The PCEF combines the different sets of authorized QoS information, that is the information received from the PCRF and the information corresponding to the predefined PCC rules. The PCRF knows the authorized QoS information of the predefined PCC rules and takes this information into account when activating them. This ensures that the combined authorized QoS of a set of PCC rules that are activated by the PCRF is within the limitations given by the subscription and operator policies regardless of whether these PCC rules are dynamically provided, predefined, or both.
Supported features include:
Other Features
This section describes some of the other features.
PCC Rule Error Handling
If the installation/activation of one or more PCC rules fails, the PCEF communicates the failure to the PCRF by including one or more Charging-Rule-Report AVP(s) in either a CCR or an RAA command for the affected PCC rules. Within each Charging-Rule-Report AVP, the PCEF identifies the failed PCC rule(s) by including the Charging-Rule-Name AVP(s) or Charging-Rule-Base-Name AVP(s), identifies the failed reason code by including a Rule-Failure-Code AVP, and includes the PCC-Rule-Status AVP.
If the installation/activation of one or more new PCC rules (that is, rules that were not previously successfully installed) fail, the PCEF sets the PCC-Rule-Status to INACTIVE for both the PUSH and the PULL modes.
If a PCC rule was successfully installed/activated, but can no longer be enforced by the PCEF, the PCEF sends the PCRF a new CCR command and includes the Charging-Rule-Report AVP. The PCEF includes the Rule-Failure-Code AVP within the Charging-Rule-Report AVP and sets the PCC-Rule-Status to INACTIVE.
In the HA/PDSN Gx implementation, the following rule failure codes are supported:
If the installation/activation of one or more PCC rules fails during RAR procedure, the RAA command is sent with the Experimental-Result-Code AVP set to DIAMETER_PCC_RULE_EVENT (5142).
Time of the Day Procedures
PCEF performs PCC rule request as instructed by the PCRF. Revalidation-Time when set by the PCRF, causes the PCEF to trigger a PCRF interaction to request PCC rules from the PCRF for an established IP-CAN session. The PCEF stops the timer once the PCEF triggers a REVALIDATION_TIMEOUT event.
When installed, the PCC rule is inactive. If Rule-Activation-Time / Rule-Deactivation-Time is specified, then the PCEF sets the rule active / inactive after that time.
Charging Control
Important: In the HA/PDSN Rel. 8 Gx implementation, offline charging is not supported.
Charging Control is the process of associating packets belonging to an SDF to a charging key, and applying online charging as appropriate. FBC handles differentiated charging of the bearer usage based on real-time analysis of the SDFs. In order to allow for charging control, the information in the PCC rule identifies the SDF and specifies the parameters for charging control. The PCC rule information may depend on subscription data.
Online charging is supported via the Gy interface. In the case of online charging, it is possible to apply an online charging action upon PCEF events (for example, re-authorization upon QoS change).
It is possible to indicate to the PCEF that interactions with the charging systems are not required for a PCC rule, that is to perform neither accounting nor credit control for this SDF, then neither online nor offline charging is performed.
Supported Features:
Important: In the HA/PDSN Rel. 8 Gx implementation, provisioning of primary or secondary charging collection function name (Offline Charging Server (OFCS) addresses) over Gx is not supported.
Charging Correlation
In the HA/PDSN Rel. 8 Gx implementation, Charging Correlation is not supported. PCRF provides the flow identifier, which uniquely identifies an IP flow in an IMS session.
Policy and Charging Control (PCC) Rules
A PCC rule enables the detection of an SDF and provides parameters for policy control and/or charging control. The purpose of the PCC rule is to:
If no PCC rule matches the packet, the packet is dropped.
The PCEF selects a PCC rule for each packet received by evaluating received packets against SDF filters of PCC rules in the order of precedence of the PCC rules. When a packet matches an SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied.
There are two types of PCC rules:
Important: A third kind of rule, the static PCC rule can be preconfigured in the chassis by the operators. Static PCC rules are not explicitly known in the PCRF, and are not under control of the PCRF. Static PCC rules are bound to general purpose bearer with no Gx control.
A PCC rule consists of:
Important: Configuring the Metering Method and Reporting Level for dynamic PCC rules is not supported.
PCC rules also include Application Function (AF) record information for enabling charging correlation between the application and bearer layer if the AF has provided this information via the Rx interface. For IMS, this includes the IMS Charging Identifier (ICID) and flow identifiers.
PCC Procedures over Gx Reference Point
Request for PCC Rules
The PCEF, via the Gx reference point, requests for PCC rules in the following instances:
PCC rules can also be requested as a consequence of a failure in the PCC rule installation/activation or enforcement without requiring an event trigger.
Provisioning of PCC Rules
The PCRF indicates, via the Rel. 8 Gx reference point, the PCC rules to be applied at the PCEF. This may be using one of the following procedures:
For each request from the PCEF or upon unsolicited provisioning, the PCRF provisions zero or more PCC rules. The PCRF may perform an operation on a single PCC rule by one of the following means:
Selecting a PCC Rule for Uplink IP Packets
If PCC is enabled, the PCEF selects the applicable PCC rule for each received uplink IP packet within an IP-CAN session by evaluating the packet against uplink SDF filters of PCRF-provided or predefined active PCC rules of this IP-CAN session in the order of the precedence of the PCC rules.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the uplink SDF filters of the PCRF-provided PCC rule is applied first.
When a packet matches an SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied. Uplink IP packets which do not match any PCC rule of the corresponding IP-CAN session are discarded.
Selecting a PCC Rule for Downlink IP Packets
If PCC is enabled, the PCEF selects a PCC rule for each received downlink IP packet within an IP-CAN session by evaluating the packet against downlink SDF filters of PCRF-provided or predefined active PCC rules of the IP-CAN session in the order of precedence of the PCC rules.
Important: When a PCRF-provided PCC rule and a predefined PCC rule have the same precedence, the downlink SDF filters of the PCRF-provided PCC rule are applied first.
When a packet matches an SDF filter, the packet matching process for that packet is completed, and the PCC rule for that filter is applied. Downlink IP packets that do not match any PCC rule of the IP-CAN session are discarded.
The following procedures are also supported:
The PCEF applies IP-CAN specific procedures to terminate the IP-CAN session. The HA/PDSN sends a MIP Revocation Request with the teardown indicator set to indicate that the termination of the entire IP-CAN session is requested. Furthermore, the PCEF applies the “Indication of IP-CAN Session Termination” procedure.
How it Works
This section describes how HA/PDSN Rel. 8 Gx Interface support works.
The following figure and table explain the IMS Authorization process between a system and IMS components that is initiated by the UE.
In this example, the Diameter Policy Control Application (DPCA) is the Gx interface to the PCRF. The interface between IMSA with PCRF is the Gx interface, and the interface between Session Manager (SessMgr) and Online Charging Service (OCS) is the Gy interface. Note that the IMSA service and DPCA are part of SessMgr on the system and separated in the figure for illustration purpose only.
HA/PDSN Rel. 8 Gx IMS Authorization Call Flow
HA/PDSN Rel. 8 Gx IMS Authorization Call flow Description
Configuring HA/PDSN Rel. 8 Gx Interface Support
To configure HA/PDSN Rel. 8 Gx Interface functionality:
1.
2.
3.
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
Configuring IMS Authorization Service at Context Level
Use the following example to configure IMSA service at context level for IMS subscribers:
configure
  context <context_name>
     ims-auth-service <imsa_service_name>
        policy-control
           diameter origin endpoint <endpoint_name>
           diameter dictionary <dictionary>
           diameter request-timeout <timeout_duration>
           diameter host-select table { 1 | 2 } algorithm round-robin
           diameter host-select row-precedence <precedence_value> table { 1 | 2 } host <primary_host_name> [ realm <primary_realm_id> ] [ secondary host <secondary_host_name> [ realm <secondary_realm_id> ] ] [ -noconfirm ]
           failure-handling cc-request-type { any-request | initial-request | terminate-request | update-request } { diameter-result-code { any-error | <result_code> [ to <end_result_code> ] } } { continue | retry-and-terminate | terminate }
           exit
        exit
     diameter endpoint <endpoint_name> [ -noconfirm ]
        origin realm <realm_name>
        use-proxy
        origin host <host_name> address <ip_address>
        no watchdog-timeout
        response-timeout <timeout_duration>
        connection timeout <timeout_duration>
        connection retry-timeout <timeout_duration>
        peer <primary_peer_name> [ realm <primary_realm_name> ] address <ip_address> [ port <port_number> ]
        peer <secondary_peer_name> [ realm <secondary_realm_name> ] address <ip_address> [ port <port_number> ]
        end
Notes:
<context_name> must be the name of the context where you want to enable IMSA service.
<imsa_service_name> must be the name of the IMSA service to be configured for Rel. 8 Gx interface authentication.
To configure the PCEF to use a pre-defined rule when the Gx fails, set the failure-handling cc-request-type CLI to continue. Policies available/in use will continue to be used and there will be no further interaction with the PCRF.
Verifying the IMSA Service Configuration
To verify the IMSA service configuration:
context <context_name>
show ims-authorization service name <imsa_service_name>
Applying IMS Authorization Service to Subscriber Template
After configuring IMSA service at the context-level, within the same context subscriber template must be configured to use the IMSA service for IMS subscribers.
Use the following example to apply IMSA service functionality to subscriber template within the context previously configured in the Configuring IMS Authorization Service at Context Level section.
configure
  context <context_name>
     subscriber default
        encrypted password <encrypted_password>
        ims-auth-service <imsa_service_name>
        ip access-group <access_group_name> in
        ip access-group <access_group_name> out
        ip context-name <context_name>
        mobile-ip home-agent <ip_address>
        active-charging rulebase <rulebase_name>
        end
Notes:
<context_name> must be the name of the context in which the IMSA service was configured.
<imsa_service_name> must be the name of the IMSA service configured for IMS authentication in the context.
policy-control charging-rule-base-name active-charging-group-of- ruledefs
Verifying the Subscriber Configuration
Verify the IMSA service configuration for subscriber(s) by entering the following command in the Exec CLI configuration mode:
show subscribers ims-auth-service <imsa_service_name>
Notes:
<imsa_service_name> must be the name of the IMSA service configured for IMS authentication.
Gathering Statistics
This section explains how to gather Rel. 8 Gx statistics and configuration information.
In the following table, the first column lists what statistics to gather, and the second column lists the action to perform.
Gathering HA/PDSN Rel. 8 Gx Statistics and Information
P-GW Rel. 8 Gx Interface Support
Introduction
The Gx reference point is located between the Policy and Charging Rules Function (PCRF) and the Policy and Charging Enforcement Function (PCEF) on the Packet Data Network (PDN) Gateway (P-GW). The Gx reference point is used for provisioning and removal of PCC rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx reference point can be used for charging control, policy control, or both, by applying AVPs relevant to the application.
The PCEF is the functional element that encompasses policy enforcement and flow based charging functionality. This functional entity is located at the P-GW. The main functions include:
Terminology and Definitions
This section describes features and terminology pertaining to Rel. 8 Gx functionality.
Volume Reporting Over Gx
This section describes the 3GPP Rel. 9 Volume Reporting over Gx feature.
License Requirements
The Volume Reporting over Gx is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
Supported Standards
The Volume Reporting over Gx feature is based on the following standard:
3GPP TS 29.212 V9.3.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 9).
Feature Overview
The Volume Reporting over Gx feature provides PCRF the capability to make real-time decisions based on the data usage by subscribers.
Important: Volume Reporting over Gx is applicable only for volume quota.
Important: In release 10.0, only total data usage reporting is supported, uplink/downlink level reporting is not supported. In 10.2 and later releases, it is supported.
Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
Important: In 12.2 and later releases, usage reporting on bearer termination is supported.
The following steps explain how Volume Reporting over Gx works:
1.
2.
3.
4.
5.
6.
Usage Monitoring
In 12.0 and later releases, enabling and disabling session usage in a single message from PCRF is supported. This is supported only if the monitoring key is associated at session level.
In 12.0 and later releases, monitoring of usage based on input/output octet threshold levels is supported. Usage is reported based on the enabled threshold level. If multiple levels are enabled, usage will be reported on all the enabled levels even if only one of the levels is breached. Monitoring will be stopped on the missing threshold levels in the response for the usage report from PCRF (expected to provide the complete set again if PCRF wants to continue monitoring on the multiple levels enabled earlier).
Total threshold level along with UL/DL threshold level in the GSU AVP is treated as an error and only total threshold level is accepted.
Usage monitoring is supported for static, predefined rules, and dynamic rule definitions.
Usage Reporting
Usage at subscriber/flow level is reported to PCRF under the following conditions:
For session-level reporting, the actual usage volume is compared with the usage volume threshold.
For rule-level reporting the rule that hits the data traffic is used to find out if the monitoring key is associated with it, and based on the monitoring key the data usage is checked. Once the condition is met, it reports the usage information to IMSA and continues monitoring. IMSA then triggers the CCR-U if “USAGE_REPORT” trigger is enabled by the PCRF. The Usage-Monitoring-Information AVP is sent in this CCR with the “Used-Service-Unit” set to the amount of data usage by subscriber.
If PCRF does not provide a new usage threshold in the usage monitoring information as a result of CCR from PCEF when the usage threshold is reached, the usage monitoring is stopped at PCEF and no usage status is reported.
In the non-standard Volume Reporting over Gx implementation, usage monitoring will be stopped once the threshold is breached, else the monitoring will continue. There will be no further usage reporting until the CCA is received.
In the case of standard implementation, this must be enabled by CLI configuration.
Important: The Usage Reporting on Revalidation Timeout feature is available by default in non-standard implementation of Volume Reporting over Gx. In 10.2 and later releases, this is configurable in the standard implementation. This is not supported in 10.0 release for standard based volume reporting.
Once the usage is reported, the usage counter is reset to zero. The PCEF continues to track data usage from the zero value after the threshold is reached and before a new threshold is provided by the PCRF. If a new usage threshold is not provided by the PCRF in the acknowledgement of an IP-CAN Session modification where its usage was reported, then usage monitoring does not continue in the PCEF for that IP CAN session and and the usage accumulated between the CCR-CCA will be discarded.
For information on how to configure the Volume Reporting over Gx feature, see the Configuring Volume Reporting over Gx section.
Rel. 9 Gx Interface
Rel. 9 Gx interface support is available on the Cisco ASR chassis running StarOS 12.2 and later releases.
P-GW Rel. 9 Gx Interface Support
Introduction
The Gx reference point is located between the Policy and Charging Rules Function (PCRF) and the Policy and Charging Enforcement Function (PCEF) on the Packet Data Network (PDN) Gateway (P-GW). The Gx reference point is used for provisioning and removal of PCC rules from the PCRF to the PCEF and the transmission of traffic plane events from the PCEF to the PCRF. The Gx reference point can be used for charging control, policy control, or both, by applying AVPs relevant to the application.
The PCEF is the functional element that encompasses policy enforcement and flow based charging functionality. This functional entity is located at the P-GW. The main functions include:
Terminology and Definitions
This section describes features and terminology pertaining to Rel. 9 Gx functionality.
Volume Reporting Over Gx
This section describes the 3GPP Rel. 9 Volume Reporting over Gx feature.
License Requirements
The Volume Reporting over Gx is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
Supported Standards
The Volume Reporting over Gx feature is based on the following standard:
3GPP TS 29.212 V9.3.0 (2010-06): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Policy and Charging Control over Gx reference point (Release 9).
Feature Overview
The Volume Reporting over Gx feature provides PCRF the capability to make real-time decisions based on the data usage by subscribers.
Important: Volume Reporting over Gx is applicable only for volume quota.
Important: In release 10.0, only total data usage reporting is supported, uplink/downlink level reporting is not supported. In 10.2 and later releases, it is supported.
Important: The PCEF only reports the accumulated usage since the last report for usage monitoring and not from the beginning.
Important: If the usage threshold is set to zero (infinite threshold), no further threshold events will be generated by PCEF, but monitoring of usage will continue and be reported at the end of the session.
Important: In 12.2 and later releases, usage reporting on bearer termination is supported.
The following steps explain how Volume Reporting over Gx works:
1.
2.
3.
4.
5.
6.
Usage Monitoring
In 12.0 and later releases, enabling and disabling session usage in a single message from PCRF is supported. This is supported only if the monitoring key is associated at session level.
In 12.0 and later releases, monitoring of usage based on input/output octet threshold levels is supported. Usage is reported based on the enabled threshold level. If multiple levels are enabled, usage will be reported on all the enabled levels even if only one of the levels is breached. Monitoring will be stopped on the missing threshold levels in the response for the usage report from PCRF (expected to provide the complete set again if PCRF wants to continue monitoring on the multiple levels enabled earlier).
Total threshold level along with UL/DL threshold level in the GSU AVP is treated as an error and only total threshold level is accepted.
Usage monitoring is supported for static, predefined rules, and dynamic rule definitions.
Usage Reporting
Usage at subscriber/flow level is reported to PCRF under the following conditions:
For session-level reporting, the actual usage volume is compared with the usage volume threshold.
For rule-level reporting the rule that hits the data traffic is used to find out if the monitoring key is associated with it, and based on the monitoring key the data usage is checked. Once the condition is met, it reports the usage information to IMSA and continues monitoring. IMSA then triggers the CCR-U if “USAGE_REPORT” trigger is enabled by the PCRF. The Usage-Monitoring-Information AVP is sent in this CCR with the “Used-Service-Unit” set to the amount of data usage by subscriber.
If PCRF does not provide a new usage threshold in the usage monitoring information as a result of CCR from PCEF when the usage threshold is reached, the usage monitoring is stopped at PCEF and no usage status is reported.
In the non-standard Volume Reporting over Gx implementation, usage monitoring will be stopped once the threshold is breached, else the monitoring will continue. There will be no further usage reporting until the CCA is received.
In the case of standard implementation, this must be enabled by CLI configuration.
Important: The Usage Reporting on Revalidation Timeout feature is available by default in non-standard implementation of Volume Reporting over Gx. In 10.2 and later releases, this is configurable in the standard implementation. This is not supported in 10.0 release for standard based volume reporting.
Once the usage is reported, the usage counter is reset to zero. The PCEF continues to track data usage from the zero value after the threshold is reached and before a new threshold is provided by the PCRF. If a new usage threshold is not provided by the PCRF in the acknowledgement of an IP-CAN Session modification where its usage was reported, then usage monitoring does not continue in the PCEF for that IP CAN session and and the usage accumulated between the CCR-CCA will be discarded.
For information on how to configure the Volume Reporting over Gx feature, see the Configuring Volume Reporting over Gx section.
 
 
Appendix D
Gy Interface Support
 
This chapter provides an overview of the Gy interface and describes how to configure the Gy interface.
Gy interface support is available on the Cisco system running StarOS 9.0 or later releases for the following products:
It is recommended that before using the procedures in this chapter you select the configuration example that best meets your service model, and configure the required elements for that model as described in the administration guide for the product that you are deploying.
This chapter describes the following topics:
Introduction
The Gy interface is the online charging interface between the PCEF/GW (Charging Trigger Function (CTF)) and the Online Charging System (Charging-Data-Function (CDF)).
The Gy interface makes use of the Active Charging Service (ACS) / Enhanced Charging Service (ECS) for real-time content-based charging of data services. It is based on the 3GPP standards and relies on quota allocation. The Online Charging System (OCS) is the Diameter Credit Control server, which provides the online charging data to the PCEF/GW. With Gy, customer traffic can be gated and billed in an online or prepaid style. Both time- and volume-based charging models are supported. In these models differentiated rates can be applied to different services based on ECS shallow- or deep-packet inspection.
In the simplest possible installation, the system will exchange Gy Diameter messages over Diameter TCP links between itself and one prepay server. For a more robust installation, multiple servers would be used. These servers may optionally share or mirror a single quota database so as to support Gy session failover from one server to the other. For a more scalable installation, a layer of proxies or other Diameter agents can be introduced to provide features such as multi-path message routing or message and session redirection features.
The following figure shows the Gy reference point in the policy and charging architecture.
PCC Logical Architecture
The following figure shows the Gy interface between CTF/Gateway/PCEF/Client running ECS and OCS (CDF/Server). Within the PCEF/GW, the Gy protocol functionality is handled in the DCCA module (at the ECS).
Gy Architecture
License Requirements
The Gy interface support is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
Supported Standards
Gy interface support is based on the following standards:
Features and Terminology
This section describes features and terminology pertaining to Gy functionality.
Charging Scenarios
Important: Online charging for events (“Immediate Event Charging” and “Event Charging with Reservation”) is not supported. Only “Session Charging with Reservation” is supported.
Session Charging with Reservation
Session Charging with Unit Reservation is used for credit control of sessions.
Decentralized Unit Determination and Centralized Rating
In this scenario, the CTF requests the reservation of units prior to session supervision. An account debit operation is carried out following the conclusion of session termination.
Centralized Unit Determination and Centralized Rating
In this scenario, the CTF requests the OCS to reserve units based on the session identifiers specified by the CTF. An account debit operation is carried out following the conclusion of session.
Decentralized Unit Determination and Decentralized Rating
Important: Decentralized Rating is not supported in this release. Decentralized Unit determination is done using CLI configuration.
In this scenario, the CTF requests the OCS to assure the reservation of an amount of the specified number of monetary units from the subscriber's account. An account debit operation that triggers the deduction of the amount from the subscriber's account is carried out following the conclusion of session establishment.
Basic Operations
Important: Immediate Event Charging is not supported in this release. “Reserve Units Request” and “Reserve Units Response” are done for Session Charging and not for Event Charging.
Online credit control uses the basic logical operations “Debit Units” and “Reserve Units”.
Session Charging with Unit Reservation (SCUR) use both the “Debit Units” and “Reserve Units” operations. SCUR uses the Session Based Credit Control procedure specified in RFC 4006. In session charging with unit reservation, when the “Debit Units” and “Reserve Units” operations are both needed, they are combined in one message.
Important: Cost-Information, Remaining-Balance, and Low-Balance-Indication AVPs are not supported.
The consumed units are deducted from the subscriber's account after service delivery. Thus, the reserved and consumed units are not necessarily the same. Using this operation, it is also possible for the CTF to modify the current reservation, including the return of previously reserved units.
Re-authorization
The server may specify an idle timeout associated with a granted quota. Alternatively, the client may have a configurable default value. The expiry of that timer triggers a re-authorization request.
Mid-session service events (re-authorisation triggers) may affect the rating of the current service usage. The server may instruct the credit control client to re-authorize the quota upon a number of different session related triggers that can affect the rating conditions.
When a re-authorization is trigger, the client reports quota usage. The reason for the quota being reported is notified to the server.
Threshold based Re-authorization Triggers
The server may optionally include an indication to the client of the remaining quota threshold that triggers a quota re-authorization.
Termination Action
The server may specify to the client the behavior on consumption of the final granted units; this is known as termination action.
Diameter Base Protocol
The Diameter Base Protocol maintains the underlying connection between the Diameter Client and the Diameter Server. The connection between the client and server is TCP based. There are a series of message exchanges to check the status of the connection and the capabilities.
Important: Acct-Application-Id is not parsed and if sent will be ignored by the PCEF/GW. In case the Result-Code is not DIAMETER_SUCCESS, the connection to the peer is closed.
Important: DWR is sent only after Tw expiry after the last message that came from the server. Say if there is continuous exchange of messages between the peers, DWR might not be sent if (Current Time - Last message received time from server) is less than Tw.
A timeout value for retrying the disconnected peer must be provided.
There is a connection timeout interval, which is also equivalent to Tw timer, wherein after a CER has been sent to the server, if there is no response received while trying to reestablish connection, the connection is closed and the state set to idle.
Diameter Credit Control Application
The Diameter Credit Control Application (DCCA) is a part of the ECS subsystem. For every prepaid customer with Diameter Credit Control enabled, whenever a session comes up, the Diameter server is contacted and quota for the subscriber is fetched.
Quota Behavior
Various forms of quotas are present that can be used to charge the subscriber in an efficient way. Various quota mechanisms provide the end user with a variety of options to choose from and better handling of quotas for the service provider.
Time Quotas
The Credit-Control server can send the CC-Time quota for the subscriber during any of the interrogation of client with it. There are also various mechanisms as discussed below which can be used in conjunction with time quota to derive variety of methods for customer satisfaction.
If packets are allowed to flow during a CCR (Update)/CCA exchange, and the Quota-Consumption-Time AVP value in the provided quota is the same as in the previously provided quota, then the Quota-Consumption-Time runs normally through this procedure. For example, if 5 seconds of a 10 second QCT timer have passed when a CCR(U) is triggered, and the CCA(U) returns 2 seconds later, then the QCT timer will expire 3 seconds after the receipt of the CCA and the remaining unaccounted 5 seconds of usage will be recorded against the new quota even though no packets were transmitted with the new quota.
A locally configurable default value in the client can be used if the server doesn't send the QCT in the CCA.
The size of the envelope is not constant as it was in Parking meter. The end of the envelope can only be determined retrospectively.
Alternatively, if this AVP is not present, a locally configurable default value in the client is used. A Quota-Holding-Time value of zero indicates that this mechanism is not used.
Validity-Time of zero is invalid. Validity-Time is relative and not absolute.
Volume Quota
The server sends the CC-Total-Octets AVP to provide volume quota to the subscriber. DCCA currently supports only CC-Total-Octets AVP, which applies equally to uplink and downlink packets. If the total of uplink and downlink packets exceeds the CC-Total-Octets granted, the quota is assumed to be exhausted.
If CC-Input-Octets and/or CC-Output-Octets is provided, the quota is counted against CC-Input-Octets and/or CC-Output-Octets respectively.
Important: Restricting usages based on CC-Input-Octets and CC_Output-Octets is not supported in this release.
Units Quota
The server can also send a CC-Service-Specific-Units quota which is used to have packets counted as units. The number of units per packet is a configurable option.
Granting Quota
Gy implementation assumes that whenever the CC-Total-Octets AVP is present, volume quota has been granted for both uplink and downlink.
If the Granted-Service-Unit contains no data, Gy treats it as an invalid CCA.
If the values are zero, it is assumed that no quota was granted.
If the AVP contains the sub AVPs without any data, it is assumed to be infinite quota.
Additional parameters relating to a category like QHT, QCT is set for the category after receiving a valid volume or time grant.
If a default quota is configured for the subscriber, and subscriber traffic is received it is counted against the default quota. The default quota is applicable only to the initial request and is not regranted during the course of the session. If subscriber disconnects and reconnects, the default quota will be applied again for the initial request.
Requesting Quota
Quotas for a particular category type can be requested using the Requested-Service-Unit AVP in the CCR. The MSCC is filled with the Rating-Group AVP which corresponds to the category of the traffic and Requested-Service-Unit AVP without any data.
The Requested-Service-Unit can contain the CC AVPs used for requesting specific quantity of time or volume grant. Gy CLI can be used to request quota for a category type.
Alternatively quota can also be requested from the server preemptively for a particular category in CCR- I. When the server grants preemptive quota through the Credit control answer response, the quota will be used only when traffic is hit for that category. Quota can be preemptively requested from the Credit Control server from the CLI.
Reporting Quota
Quotas are reported to the server for number of reasons including:
For the above cases except for QHT and Final, the Requested-Service-Unit AVP is present in the CCR.
Reporting Reason is present in CCR to let the server know the reason for the reporting of Quota. The Reporting-Reason AVP can be present either in MSCC level or at Used Service Unit (USU) level depending on whether the reason applies to all quotas or to single quota.
When one of these conditions is met, a CCR Update is sent to the server containing a Multiple-Services-Credit-Control AVP(s) indicating the reason for reporting usage in the Reporting-Reason and the appropriate value(s) for Trigger, where appropriate. Where a threshold was reached, the DCCA still has the amount of quota available to it defined by the threshold.
For all other reporting reasons the client discards any remaining quota and either discards future user traffic matching this category or allows user traffic to pass, or buffers traffic according to configuration.
For Reporting-Reason of Rating Condition Change, Gy requires the Trigger Type AVP to be present as part of the CCR to indicate which trigger event caused the reporting and re-authorization request.
For Reporting-Reason of end user service denied, this happens when a category is blacklisted by the credit control server, in this case a CCR-U is sent with used service unit even if the values as zero. When more quota is received from the server for that particular category, the blacklisting is removed.
If a default quota has been set for the subscriber then the usage from the default quota is deducted from the initial GSU received for the subscriber for the Rating Group or Rating Group and Service ID combination.
Default Quota Handling
Thresholds
The Gy client supports the following threshold types:
A threshold is always associated with a particular quota and a particular quota type. in the Multiple-Services-Credit-Control AVP, the Time-Quota-Threshold, Volume-Quota-Threshold, and Unit-Quota-Threshold are optional AVPs.
They are expressed as unsigned numbers and the units are seconds for time quota, octets for volume quota and units for service specific quota. Once the quota has reached its threshold, a request for more quotas is triggered toward the server. User traffic is still allowed to flow. There is no disruption of traffic as the user still has valid quota.
The Gy sends a CCR Update with a Multiple-Services-Credit-Control AVP containing usage reported in one or more User-Service-Unit AVPs, the Reporting-Reason set to THRESHOLD and the Requested-Service-Unit AVP without data.
When quota of more than one type has been assigned to a category, each with its own threshold, then the threshold is considered to be reached once one of the unit types has reached its threshold even if the other unit type has not been consumed.
When reporting volume quota, the DCCA always reports uplink and downlink separately using the CC-Input-Octets AVP and the CC-Output-Octets AVP, respectively.
On receipt of more quotas in the CCA the Gy discard any quota not yet consumed since sending the CCR. Thus the amount of quota now available for consumption is the new amount received less any quota that may have been consumed since last sending the CCR.
Conditions for Reauthorization of Quota
Quota is re-authorized/requested from the server in case of the following scenarios:
Discarding or Allowing or Buffering Traffic to Flow
Whenever Gy is waiting for CCA from the server, there is a possibility of traffic for that particular traffic type to be encountered in the Gy. The behavior of what needs to be done to the packet is determined by the configuration. Based on the configuration, the traffic is either allowed to pass or discarded or buffered while waiting for CCA from the server.
This behavior applies to all interrogation of client with server in the following cases:
In addition to allowing or discarding user traffic, there is an option available in case of quota exhausted or no quota circumstances to buffer the traffic. This typically happens when the server has been requested for more quota, but a valid quota response has not been received from the server, in this case the user traffic is buffered and on reception of valid quota response from the server the buffered traffic is allowed to pass through.
Procedures for Consumption of Time Quota
If the QCT value is changed during intermediate interrogations, then the new QCT comes into effect from the time the CCA is received. For instance, if the QCT is deactivated in the CCA, then quota consumptions resume normally even without any packet flow. Or if the QCT is activated from deactivation, then the quota consumption resume only after receiving the first packet after CCA.
QHT timer is reset every time a packet arrives.
Envelope Reporting
The server may determine the need for additional detailed reports identifying start time and end times of specific activity in addition to the standard quota management. The server controls this by sending a CCA with Envelope-Reporting AVP with the appropriate values. The DCCA client, on receiving the command, will monitor for traffic for a period of time controlled by the Quota-Consumption-Time AVP and report each period as a single envelope for each Quota-Consumption-Time expiry where there was traffic. The server may request envelope reports for just time or time and volume. Reporting the quota back to the server, is controlled by Envelope AVP with Envelope-Start-Time and Envelope-End-Time along with usage information.
Credit Control Request
Credit Control Request (CCR) is the message that is sent from the client to the server to request quota and authorization. CCR is sent before the establishment of MIP session, and at the termination of the MIP session. It can be sent during service delivery to request more quotas.
If the MSCC AVP is missing in CCA-Update it is treated as invalid CCA and the session is terminated.
The following figure depicts the call flow for a simple call request in the GGSN / P-GW /IPSG Gy implementation.
Gy Call Flow for Simple Call Request
The following figure depicts the call flow for a simple call request in the HA Gy implementation.
Gy Call Flow for Simple Call Request
Tx Timer Expiry Behavior
A timer is started each time a CCR is sent out from the system, and the response has to arrive within Tx time. The timeout value is configurable in the Diameter Credit Control Configuration mode.
In case there is no response from the Diameter server for a particular CCR, within Tx time period, and if there is an alternate server configured, the CCR is sent to the alternate server after Tw expiry as described in “Tw Timer expiry behavior” section.
It also depends on the Credit-Control-Session-Failover AVP value for the earlier requests. If this AVP is present and is coded to FAILOVER_SUPPORTED then the credit-control message stream is moved to the secondary server, in case it is configured. If the AVP value is FAILOVER_NOT SUPPORTED, then the call is dropped in case of failures, even if a secondary server is configured.
Redirection
In the Final-Unit-Indication AVP, if the Final-Action is REDIRECT or Redirect-Server AVP is present at command level, redirection is performed.
The redirection takes place at the end of consumption of quota of the specified category. The GY sends a CCR-Update without any RSU or Rating-Group AVP so that the server does not give any more quotas.
If the Final-Action AVP is RESTRICT_ACCESS, then according to the settings in Restriction-Filter-Rule AVP or Filter-Id AVP. GY sends CCR-Update to the server with used quota.
Triggers
The Diameter server can provide with the triggers for which the client should reauthorize a particular category. The triggers can be configured locally as well but whatever trigger is present in the CCA from the server will have precedence.
Important: In this release, Gy triggers are not supported for HA.
The trigger types that are supported are:
On any event as described in the Trigger type happens, the client reauthorizes quota with the server. The reporting reason is set as RATING_CONDITION_CHANGE.
Tariff Time Change
The tariff change mechanism applies to each category instance active at the time of the tariff change whenever the server indicated it should apply for this category.
The concept of dual coupon is supported. Here the server grants two quotas, which is accompanied by a Tariff-Time-Change, in this case the first granted service unit is used until the tariff change time, once the tariff change time is reached the usage is reported up to the point and any additional usage is not accumulated, and then the second granted service unit is used.
If the server expects a tariff change to occur within the validity time of the quota it is granting, then it includes the Tariff-Time-Change AVP in the CCA. The DCCA report usage, which straddles the change time by sending two instances of the Used-Service-Unit AVP, one with Tariff-Change-Usage set to UNIT_BEFORE_TARIFF_CHANGE, and one with Tariff-Change-Usage set to UNIT_AFTER_TARIFF_CHANGE, and this independently of the type of units used by application. Both Volume and Time quota are reported in this way.
The Tariff time change functionality can as well be done using Validity-Time AVP, where in the Validity-Time is set to Tariff Time change and the client will reauthorize and get quota at Validity-Time expiry. This will trigger a lot of reauthorize request to the server at a particular time and hence is not advised.
Tariff-Time-Usage AVP along with the Tariff-Time-Change AVP in the answer message to the client indicates that the quotas defined in Multiple-Services-Credit-Control are to be used before or after the Tariff Time change. Two separate quotas are allocated one for before Tariff-Time-Change and one for after Tariff-Time-Change. This gives the flexibility to the operators to allocate different quotas to the users for different periods of time. In this case, the DCCA should not send the Before-Usage and After-Usage counts in the update messages to the server. When Tariff-Time-Change AVP is present without Tariff-Time-Usage AVP in the answer message, then the quota is used as in single quota mechanism and the client has to send before usage and after usage quotas in the updates to the server.
Important: In this release, Gy does not support UNIT_INDETERMINATE value.
Final Unit Indication
The Final-Unit-Indication AVP can be present in the CCA from the server to indicate that the given quota is the final quota from the server and the corresponding action as specified in the AVP needs to be taken.
Final Unit Indication at Command Level
Gy currently does not support FUI AVP at command level. If this AVP is present at command level it is ignored. If the FUI AVP is present at command level and the Final-Unit-Action AVP set to TERMINATE, Gy sends a CCR-Terminate at the expiry of the quota, with all quotas in the USU AVP.
Important: FUI AVP at command level is only supported for Terminate action.
Final Unit Indication at MSCC Level
If the Final-Unit-Indication AVP is present at MSCC level, and if the Final-Unit-Action AVP is set to TERMINATE, a CCR-Update is sent at the expiry of the allotted quota and report the usage of the category that is terminated.
For information on redirection cases refer to Redirection section.
Credit Control Failure Handling
CCFH AVP defines what needs to be done in case of failure of any type between the client and the server. The CCFH functionality can be defined in configuration but if the CCFH AVP is present in the CCA, it takes precedence. CCFH AVP gives flexibility to have different failure handling.
Gy supports the following Failure Handling options:
CCFH with Failover Supported
In case there is a secondary server is configured and if the CC-Session-Failover AVP is set to FAILOVER_SUPPORTED, the following behavior takes place:
CCFH with Failover Not Supported
In case there is a secondary server configured and if the CC-Session-Failover AVP is set to FAILOVER_NOT_SUPPORTED, the following behavior takes place as listed below. Same is the case if there is no secondary server configured on the system.
Failover Support
The CC-Session-Failover AVP and the Credit-Control-Failure-Handling (CCFH) AVP may be returned by the CC server in the CCA-I, and are used by the DCCA to manage the failover procedure. If they are present in the CCA they override the default values that are locally configured in the system.
If the CC-Session-Failover is set to FAILOVER_NOT_SUPPORTED, a CC session will never be moved to an alternative Diameter Server.
If the value of CC-Session-Failover is set to FAILOVER_SUPPORTED, then the Gy attempts to move the CC session to the alternative server when it considers a request to have failed, i.e:
The CCFH determines the behavior of the client in fault situations. If the Tx timer expires then based on the CCFH value the following actions are taken:
After the failover action has been attempted, and if there is still a failure to send or temporary error, depending on the CCFH action, the following action is taken:
Recovery Mechanisms
DCCA supports a recovery mechanism that is used to recover sessions without much loss of data in case of Session Manager failures. There is a constant check pointing of Gy data at regular intervals and at important events like update, etc.
For more information on recovery mechanisms, please refer to the System Administration Guide.
Error Mechanisms
Unsupported AVPs
All unsupported AVPs from the server with “M” bit set are ignored.
Invalid Answer from Server
If there is an invalid answer from the server, Gy action is dependent on the CCFH setting:
Result Code Behavior
 
For all other permanent/transient failures, Gy action is dependent on the CCFH setting.
Supported AVPs
The Gy functionality supports the following AVPs:
Gy supports this AVP only in USU.
Gy supports this AVP only in USU.
Gy currently does not support EVENT_REQUEST value.
Gy does not support this AVP in RSU.
Gy does not support this AVP in RSU.
Supported at Multiple-Services-Credit-Control grouped AVP level and not at command level.
Fully supported at Multiple-Services-Credit-Control grouped AVP level and partially supported (TERMINATE) at command level.
Gy currently supports only URL (2) value.
Gy does NOT support UNIT_INDETERMINATE (2) value.
Gy sends only incremental counts for all the AVPs from the last CCA-U.
Gy currently supports only IMEISV value.
Cisco GGSN and P-GW support IMEISV by default.
This AVP is present only in CCR-I.
This optional AVP is present only in CCA.
This optional AVP is present only in the CCA command. It is contained in the Multiple-Services-Credit-Control AVP. It applies equally to the granted time quota and to the granted volume quota.
Gy currently does not support the POOL_EXHAUSTED (8) value. It is used in case of credit-pooling which is currently not supported.
Only PS-Information is supported.
The Gy server may include this AVP in an Multiple-Services-Credit-Control AVP when granting time quota.
Unsupported AVPs
This section lists the AVPs that are NOT supported.
The PCEF/GW ignores this AVP if no PS free format data is stored for the online charging session.
Configuring Gy Interface Support
To configure Gy interface support:
1.
2.
3.
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Important: Commands used in the configuration examples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
Configuring GGSN / P-GW / IPSG Gy Interface Support
To configure the standard Gy interface support for GGSN/P-GW/IPSG, use the following configuration:
configure
  context <context_name>
     diameter endpoint <endpoint_name>
        origin realm <realm>
        origin host <diameter_host> address <ip_address>
        peer <peer> realm <realm> address <ip_address>
        exit
     exit
  active-charging service <ecs_service_name>
     credit-control [ group <cc_group_name> ]
        diameter origin endpoint <endpoint_name>
        diameter peer-select peer <peer> realm <realm>
        diameter pending-timeout <timeout_period>
        diameter session failover
        diameter dictionary <dictionary>
        failure-handling initial-request continue
        failure-handling update-request continue
        failure-handling terminate-request continue
        exit
     exit
  context <context_name>
     apn <apn_name>
        selection-mode sent-by-ms
        ims-auth-service <service>
        ip access-group <access_list_name> in
        ip access-group <access_list_name> out
        ip context-name <context_name>
        active-charging rulebase <rulebase_name>
        credit-control-group <cc_group_name>
        end
Notes:
For information on configuring IP access lists, refer to the Access Control Lists chapter in the System Administration Guide.
For more information on configuring ECS ruledefs, refer to the ACS Ruledef Configuration Mode Commands chapter in the Command Line Interface Reference.
For more information on configuring ECS charging actions, refer to the ACS Charging Action Configuration Mode Commands chapter in the Command Line Interface Reference.
For more information on configuring ECS rulebases, refer to the ACS Rulebase Configuration Mode Commands chapter in the Command Line Interface Reference.
Configuring HA / PDSN Gy Interface Support
To configure HA / PDSN Gy interface support, use the following configuration:
configure
  context <context_name>
     diameter endpoint <endpoint_name>
        origin realm <realm>
        origin host <diameter_host> address <ip_address>
        peer <peer> realm <realm> address <ip_address>
        exit
     exit
  active-charging service <ecs_service_name>
     ruledef <ruledef_name>
        ip any-match = TRUE
        exit
     charging-action <charging_action_name>
        content-id <content_id>
        cca charging credit rating-group <rating_group>
        exit
     rulebase <rulebase_name>
        action priority <action_priority> ruledef <ruledef_name> charging-action <charging_action_name>
        exit
     credit-control [ group <cc_group_name> ]
        diameter origin endpoint <endpoint_name>
        diameter peer-select peer <peer> realm <realm>
        diameter pending-timeout <timeout>
        diameter session failover
        diameter dictionary <dictionary>
        failure-handling initial-request continue
        failure-handling update-request continue
        failure-handling terminate-request continue
        pending-traffic-treatment noquota buffer
        pending-traffic-treatment quota-exhausted buffer
        exit
     exit
  context <context_name>
     subscriber default
        ip access-group <acl_name> in
        ip access-group <acl_name> out
        ip context-name <context_name>
        active-charging rulebase <rulebase_name>
        credit-control-group <cc_group_name>
        end
Notes:
For information on configuring IP access lists, refer to the Access Control Lists chapter in the Systems Administration Guide.
For more information on configuring ECS ruledefs, refer to the ACS Ruledef Configuration Mode Commands chapter in the Command Line Interface Reference.
For more information on configuring ECS charging actions, refer to the ACS Charging Action Configuration Mode Commands chapter in the Command Line Interface Reference.
For more information on configuring ECS rulebases, refer to the ACS Rulebase Configuration Mode Commands chapter in the Command Line Interface Reference.
Gathering Statistics
This section explains how to gather Gy and related statistics and configuration information.
In the following table, the first column lists what statistics to gather, and the second column lists the action to perform.
show active-charging credit-control session-states [ rulebase <rulebase_name> ] [ content-id <content_id> ]
 
 
Appendix E
ICAP Interface Support
 
This chapter provides information on configuring the external Active Content Filtering servers for a core network service subscriber. This chapter also describes the configuration and commands that are used to implement this feature.
It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in respective product Administration Guide, before using the procedures in this chapter.
The following products currently support ICAP interface functionality:
ICAP Interface Support Overview
This feature supports streamlined ICAP interface to leverage Deep Packet Inspection (DPI) to enable external application servers to provide their services without performing DPI, and without being inserted in the data flow. For example with an external Active Content Filtering (ACF) Platform.
A high-level view of the streamlined ICAP interface support for external ACF is shown in the following figure:
High-Level View of Streamlined ICAP Interface with external ACF
The system with ECS is configured to support DPI and the system uses this capability for content charging as well.
If a subscriber initiates a WAP (WAP1.x or WAP2.0) or Web session, the subsequent GET/POST request is detected by the DPI function. The URL of the GET/POST request is extracted and passed, along with subscriber identification information and the subscriber request, in an ICAP message to the application server. The application server checks the URL on the basis of its category and other classifications like, type, access level, content category and decides if the request should be authorized, blocked, or redirected by answering to the GET/POST with:
Depending on the response received, the system with ECS will either pass the request unmodified, or discard the message and respond to the subscriber with the appropriate redirection or block message.
Content charging is performed by the Active Charging Service (ACS) only after the request has been controlled by the application server. This guarantees the appropriate interworking between the external application and content-based billing. In particular, this guarantees that charging will be applied to the appropriate request in case of redirection, and that potential charging-based redirections (i.e. Advice of Charge, Top Up page, etc.) will not interfere with the decisions taken by the application server.
Functions of the ACF include:
Failure Action on Retransmitted Packets
ICAP rating is enabled for retransmitted packet when default ICAP failure action was taken on an ICAP request for that flow. ICAP default failure action is taken on the pending ICAP request for a connection when the connection needs to be reset and there is no other redundant connection available. For example, in the ICAP request timeout and ICAP connection timeout scenarios. In these cases the retransmitted packet in the uplink direction is sent for ICAP rating again.
In case of WAP CO, uplink retransmitted packet for the WAP transactions for which ICAP failure action was taken will be sent for ICAP rating. WSP header of the retransmitted packet is not parsed by the WSP analyzer. The URL received in the previous packet for that transaction is used for ICAP rating. If failure action was taken on multiple WTP transactions for the same flow (case: WTP concatenated GET request) then uplink retransmitted packet for each of the transaction is sent for rating again.
In case of HTTP, uplink retransmitted packets for the HTTP flow on which ICAP failure action is taken is sent for ICAP rating. The URL present in the current secondary session (last uplink request) is used for ICAP rating. However, if there were multiple outstanding ICAP request for the same flow (pipelined request) then for the retransmitted packet the URL that will be sent for rating will be that of the last GET request.
Retransmission in various cases of failure-action taken on re-transmitted packets when the ICAP response is not received for the original request and the retransmitted request comes in:
Supported Networks and Platforms
This feature supports ST16 and Cisco Chassis for the core network services configured on the system.
License Requirements
External Content Filtering Server support through Internet Content Adaptation Protocol (ICAP) interface is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements.
For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
Configuring ICAP Interface Support
This section describes how to configure the Content Filtering Server Group (CFSG) through Internet Content Adaptation Protocol (ICAP) interface between ICAP client and ACF server (ICAP server).
Important: This section provides the minimum instruction set for configuring external content filtering servers on ICAP interface on the system. For more information on commands that configure additional parameters and options, refer to CFSG Configuration Mode Commands chapter in Command Line Interface Reference.
To configure the system to provide ICAP interface support for external content filtering servers:
Step 1
Step 2
Step 3
Step 4
Optional. Configure the charging action to forward HTTP/WAP GET request to external content filtering servers on ICAP interface in Active Charging Configuration mode by applying the example configuration in the Configuring Charging Action for ICAP Server Group section.
Step 5
Step 6
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Creating ICAP Server Group and Address Binding
Use the following example to create the ICAP server group and bind the IP addresses:
configure
  context <icap_ctxt_name> [ -noconfirm ]
     content-filtering server-group <icap_svr_grp_name> [ -noconfirm ]
        origin address <ip_address>
        end
Notes:
<ip_address> is local IP address of the CFSG endpoint.
Configuring ICAP Server and Other Parameters
Use the following example to configure the active content filtering (ICAP server) and other related parameters:
configure
  context <icap_context_name>
     content-filtering server-group <icap_server_grp_name>
        icap server <ip_address> [port <port_number>][max <max_msgs>][priority <priority>]
        deny-message <msg_string>
        response-timeout <timeout>
        connection retry-timeout <retry_timeout>
        failure-action {allow | content-insertion <content_string> | discard | redirect-url <url> | terminate-flow}
        dictionary {custom1 | custom2 | standard}
        end
Notes:
The maximum outstanding request per ICAP connection configured using the optional max <max_msgs> keyword is limited to one. Therefore, any other value configured using the max keyword will be ignored.
Optional. To configure the ICAP URL extraction behavior, in the Content Filtering Server Group configuration mode, enter the following command:
url-extraction { after-parsing | raw }
By default, percent-encoded hex characters in URLs sent from the ACF client to the ICAP server will be converted to corresponding ASCII characters and sent.
Configuring ECS Rulebase for ICAP Server Group
Use the following example to configure the content filtering mode to ICAP server mode in the ECS rulebase for content filtering:
configure
  require active-charging [optimized-mode]
  active-charging service <acs_svc_name> [-noconfirm]
     rulebase <rulebase_name> [-noconfirm]
        content-filtering mode server-group <cf_server_group>
        end
Notes:
In StarOS 8.1, the optimized-mode keyword enables ACS in the Optimized mode, wherein ACS functionality is managed by SessMgrs. In StarOS 8.1, ACS must be enabled in the Optimized mode.
In StarOS 8.3, the optimized-mode keyword is obsolete. With or without this keyword ACS is always enabled in Optimized mode.
In StarOS 8.0 and StarOS 9.0 and later, the optimized-mode keyword is not available.
Configuring Charging Action for ICAP Server Group
Use the following example to configure the charging action to forward HTTP/WAP GET request to ICAP server for content processing:
configure
  active-charging service <acs_svc_name>
     charging-action <charging_action_name> [ -noconfirm ]
        content-filtering processing server-group
        end
Verifying the ICAP Server Group Configuration
This section explains how to display and review the configurations after saving them in a .cfg file and also to retrieve errors and warnings within an active configuration for a service.
Important: All commands listed here are under Exec mode. Not all commands are available on all platforms.
These instructions are used to verify the configuration for this feature.
Step 1
show content-filtering server-group
The following is a sample output. In this example, an ICAP Content Filtering server group named icap_cfsg1 was configured.
Content Filtering Group:     icap_cfsg1
  Context:                     icap1
  Origin Address:              1.2.3.4
  ICAP Address(Port):          1.2.3.4(1344)
  Max Outstanding:             256
  Priority:                    1
  Response Timeout:      30(secs)      Connection Retry Timeout:      30(secs)
  Dictionary:                   standard
  Timeout Action:               terminate-flow
  Deny Message:                 "Service Not Subscribed"
  URL-extraction:                after-parsing
  Content Filtering Group Connections: NONE
Total content filtering groups matching specified criteria:  1
Step 2
show configuration errors
 
 
Appendix F
IP Security
 
This chapter provides information on configuring an enhanced or extended service. The product Administration Guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in the respective product Administration Guide, before using the procedures in this chapter.
Important: The IP Security is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
Caution: IPSec parameter configurations saved using this release may not function properly with older software releases.
This chapter contains the following sections:
Overview
IP Security (IPSec) is a suite of protocols that interact with one another to provide secure private communications across IP networks. These protocols allow the system to establish and maintain secure tunnels with peer security gateways. IPSec can be implemented on the system for the following applications:
PDN Access: Subscriber IP traffic is routed over an IPSec tunnel from the system to a secure gateway on the packet data network (PDN) as determined by access control list (ACL) criteria. This application can be implemented for both core network service and HA-based systems. The following figure shows IPSec configurations.
IPSec Applications
Mobile IP: Mobile IP control signals and subscriber data is encapsulated in IPSec tunnels that are established between foreign agents (FAs) and home agents (HAs) over the Pi interfaces.
Important: Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.
L2TP: L2TP-encapsulated packets are routed from the system to an LNS/secure gateway over an IPSec tunnel.
Note that: IPSec can be implemented for both attribute-based and compulsory tunneling applications for 3GPP2 services.
Applicable Products and Relevant Sections
The IPSec feature is supported for various products. The following table indicates the products on which the feature is supported and the relevant sections within the chapter that pertain to that product.
IPSec Terminology
There are four items related to IPSec support on the system that must be understood prior to beginning configuration. They are:
Crypto Access Control List (ACL)
As described in the IP Access Control Lists chapter of this guide, ACLs on the system define rules, usually permissions, for handling subscriber data packets that meet certain criteria. Crypto ACLs, however, define the criteria that must be met in order for a subscriber data packet to be routed over an IPSec tunnel.
Unlike other ACLs that are applied to interfaces, contexts, or one or more subscribers, crypto ACLs are matched with crypto maps. In addition, crypto ACLs contain only a single rule while other ACL types can consist of multiple rules.
Prior to routing, the system examines the properties of each subscriber data packet. If the packet properties match the criteria specified in the crypto ACL, the system will initiate the IPSec policy dictated by the crypto map.
Transform Set
Transform Sets are used to define IPSec security associations (SAs). IPSec SAs specify the IPSec protocols to use to protect packets.
Transform sets are used during Phase 2 of IPSec establishment. In this phase, the system and a peer security gateway negotiate one or more transform sets (IPSec SAs) containing the rules for protecting packets. This negotiation ensures that both peers can properly protect and process the packets.
ISAKMP Policy
Internet Security Association Key Management Protocol (ISAKMP) policies are used to define Internet Key Exchange (IKE) SAs. The IKE SAs dictate the shared security parameters (i.e. which encryption parameters to use, how to authenticate the remote peer, etc.) between the system and a peer security gateway.
During Phase 1 of IPSec establishment, the system and a peer security gateway negotiate IKE SAs. These SAs are used to protect subsequent communications between the peers including the IPSec SA negotiation process.
Crypto Map
Crypto Maps define the tunnel policies that determine how IPSec is implemented for subscriber data packets.
There are three types of crypto maps supported by the system. They are:
Manual Crypto Maps
These are static tunnels that use pre-configured information (including security keys) for establishment. Because they rely on statically configured information, once created, the tunnels never expire; they exist until their configuration is deleted.
Manual crypto maps define the peer security gateway to establish a tunnel with, the security keys to use to establish the tunnel, and the IPSec SA to be used to protect data sent/received over the tunnel. Additionally, manual crypto maps are applied to specific system interfaces.
Important: Because manual crypto map configurations require the use of static security keys (associations), they are not as secure as crypto maps that rely on dynamically configured keys. Therefore, it is recommended that they only be configured and used for testing purposes.
ISAKMP Crypto Maps
These tunnels are similar to manual crypto maps in that they require some statically configured information such as the IP address of a peer security gateway and that they are applied to specific system interfaces.
However, ISAKMP crypto maps offer greater security because they rely on dynamically generated security associations through the use of the Internet Key Exchange (IKE) protocol.
When ISAKMP crypto maps are used, the system uses the pre-shared key configured for map as part of the Diffie-Hellman (D-H) exchange with the peer security gateway to initiate Phase 1 of the establishment process. Once the exchange is complete, the system and the security gateway dynamically negotiate IKE SAs to complete Phase 1. In Phase 2, the two peers dynamically negotiate the IPSec SAs used to determine how data traversing the tunnel will be protected.
Dynamic Crypto Maps
These tunnels are used for protecting L2TP-encapsulated data between the system and an LNS/security gateway or Mobile IP data between an FA service configured on one system and an HA service configured on another.
The system determines when to implement IPSec for L2TP-encapsulated data either through attributes returned upon successful authentication for attribute based tunneling, or through the configuration of the LAC service used for compulsory tunneling.
The system determines when to implement IPSec for Mobile IP based on RADIUS attribute values as well as the configurations of the FA and HA service(s).
Implementing IPSec for PDN Access Applications
This section provides information on the following topics:
In covering these topics, this section assumes that ISAKMP crypto maps are configured/used as opposed to manual crypto maps.
How the IPSec-based PDN Access Configuration Works
The following figure and the text that follows describe how sessions accessing a PDN using IPSec are processed by the system.
IPSec PDN Access Processing
IPSec PDN Access Processing
Configuring IPSec Support for PDN Access
This section provides a list of the steps required to configure IPSec functionality on the system in support of PDN access. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the system was previously configured to support subscriber data sessions either as a core service or an HA. In addition, parameters configured using this procedure must be configured in the same destination context on the system.
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Implementing IPSec for Mobile IP Applications
This section provides information on the following topics:
How the IPSec-based Mobile IP Configuration Works
The following figure and the text that follows describe how Mobile IP sessions using IPSec are processed by the system.
IPSec-based Mobile IP Session Processing
IPSec-based Mobile IP Session Processing
Important: Once an IPSec tunnel is established between an FA and HA for a particular subscriber, all new Mobile IP sessions using the same FA and HA are passed over the tunnel regardless of whether or not IPSec is supported for the new subscriber sessions. Data for existing Mobile IP sessions is unaffected.
Configuring IPSec Support for Mobile IP
This section provides a list of the steps required to configure IPSec functionality on the system in support of Mobile IP. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the systems were previously configured to support subscriber data sessions either as an FA or an HA.
Step 1
The transform set(s) must be configured in the same context as the FA service.
Step 2
The ISAKMP policy(ies) must be configured in the same context as the FA service.
Step 3
The crypto map(s) must be configured in the same context as the FA service.
Step 4
Important: Though the use of DPD is optional, it is recommended in order to ensure service availability.
Step 5
Step 6
The transform set(s) must be configured in the same context as the HA service.
Step 7
The ISAKMP policy(ies) must be configured in the same context as the HA service.
Step 8
The crypto map(s) must be configured in the same context as the HA service.
Step 9
Important: Though the use of DPD is optional, it is recommended in order to ensure service availability.
Step 10
Step 11
Step 12
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Implementing IPSec for L2TP Applications
This section provides information on the following topics:
How IPSec is Used for Attribute-based L2TP Configurations
The following figure and the text that follows describe how IPSec-encrypted attribute-based L2TP sessions are processed by the system.
Attribute-based L2TP, IPSec-Encrypted Session Processing
Attribute-based L2TP, IPSec-Encrypted Session Processing
Configuring Support for L2TP Attribute-based Tunneling with IPSec
This section provides a list of the steps required to configure IPSec functionality on the system in support of attribute-based L2TP tunneling. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the system was previously configured to support subscriber data sessions and L2TP tunneling either as a PDSN or an HA. In addition, with the exception of subscriber attributes, all other parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.
Step 1
Step 2
Step 3
Step 4
Step 5
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
How IPSec is Used for PDSN Compulsory L2TP Configurations
The following figure and the text that follows describe how IPSec-encrypted PDSN compulsory L2TP sessions are processed by the system.
PDSN Compulsory L2TP, IPSec-Encrypted Session Processing
PDSN Compulsory L2TP, IPSec-Encrypted Session Processing
Configuring Support for L2TP PDSN Compulsory Tunneling with IPSec
This section provides a list of the steps required to configure IPSec functionality on the system in support of PDSN compulsory L2TP tunneling. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the system was previously configured to support PDSN compulsory tunneling subscriber data sessions. In addition, all parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.
Step 1
Step 2
Step 3
Step 4
Step 5
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
How IPSec is Used for L2TP Configurations on the GGSN
The following figure and the text that follows describe how IPSec-encrypted attribute-based L2TP sessions are processed by the system.
GGSN PDP Context Processing with IPSec-Encrypted L2TP
GGSN PDP Context Processing with IPSec-Encrypted L2TP
Configuring GGSN Support for L2TP Tunneling with IPSec
This section provides a list of the steps required to configure the GGSN to encrypt L2TP tunnels using IPSEC. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the system was previously configured to support subscriber PDP contexts and L2TP tunneling either as a GGSN. In addition, all parameters configured using this procedure must be configured in the same destination context on the system as the LAC service.
Step 1
Step 2
Step 3
Step 4
Step 5
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Transform Set Configuration
This section provides instructions for configuring transform sets on the system.
Important: This section provides the minimum instruction set for configuring transform set on your system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Transform Configuration Mode chapters in the Command Line Interface Reference.
To configure the crypto transform set for IPSec:
Step 1
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring Transform Set
Use the following example to create the crypto transform set on your system:
configure
  context <ctxt_name>
     crypto ipsec transform-set <transform_name> ah hmac { md5-96 | none |sha1-96 } esp hmac { { md5-96 | none | sha1-96 } { cipher {des-cbc | 3des-cbc | aes-cbc } | none }
        mode { transport | tunnel }
        end
Notes:
<ctxt_name> is the system context in which you wish to create and configure the crypto transform set(s).
<transform_name> is the name of the crypto transform set in the current context that you want to configure for IPSec configuration.
For more information on parameters, refer to the IPSec Transform Configuration Mode Commands chapter in the Command Line Interface Reference.
Verifying the Crypto Transform Set Configuration
These instructions are used to verify the crypto transform set(s) was/were configured.
Step 1
show crypto transform-set transform_name
This command produces an output similar to that displayed below using the configuration of a transform set named test1.
Transform-Set test1 :
AH : none
ESP :hmac md5-96, 3des-cbc
Encaps Mode: TUNNEL
ISAKMP Policy Configuration
This section provides instructions for configuring ISAKMP policies on the system. ISAKMP policy configuration is only required if the crypto map type is either ISAKMP or Dynamic.
Important: This section provides the minimum instruction set for configuring ISAKMP policies on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and ISAKMP Configuration Mode Commands chapters in the Command Line Interface Reference.
To configure the ISAKMP policy for IPSec:
Step 1
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring ISAKMP Policy
Use the following example to create the ISAKMP policy on your system:
configure
  context <ctxt_name>
     ikev1 policy <priority>
        encryption { 3des-cbc | des-cbc }
        hash { md5 | sha1 }
        group { 1 | 2 | 3 | 4 | 5 }
        lifetime <time>
        end
Notes:
<ctxt_name> is the system context in which you wish to create and configure the ISAKMP policy.
<priority> dictates the order in which the ISAKMP policies are proposed when negotiating IKE SAs.
For more information on parameters, refer to the ISAKMP Configuration Mode Commands chapter in the Command Line Interface Reference.
Verifying the ISAKMP Policy Configuration
These instructions are used to verify the ISAKMP policy configuration.
Step 1
show crypto isakmp policy priority
This command produces an output similar to that displayed below that displays the configuration of an ISAKMP policy with priority 1.
1 ISAKMP Policies are configured
Priority : 1
Authentication Method : preshared-key
Lifetime : 120 seconds
IKE group : 5
hash : md5
encryption : 3des-cbc
Caution: Modification(s) to an existing ISAKMP policy configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
ISAKMP Crypto Map Configuration
This section provides instructions for configuring ISAKMP crypto maps.
Important: This section provides the minimum instruction set for configuring ISAKMP crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Map ISAKMP Configuration Mode chapters in the Command Line Interface Reference.
To configure the ISAKMP crypto maps for IPSec:
Step 1
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring ISAKMP Crypto Maps
Use the following example to create the ISAKMP crypto map on your system:
configure
  context <ctxt_name>
     crypto map <map_name> ipsec-isakmp
        set peer <agw_address>
        set isakmp preshared-key <isakmp_key>
        set mode { aggressive | main }
        set pfs { group1 | group2 | group5 }
        set transform-set <transform_name>
        match address <acl_name> [ preference ]
        match crypto-group <group_name> { primary | secondary }
        end
Notes:
<ctxt_name> is the system context in which you wish to create and configure the ISAKMP crypto maps.
<map_name> is name by which the ISAKMP crypto map will be recognized by the system.
<acl_name> is name of the pre-configured ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. This is an optional parameter.
<group_name> is name of the Crypto group configured in the same context. It is used for configurations using the IPSec Tunnel Failover feature. This is an optional parameter. For more information, refer to the Redundant IPSec Tunnel Fail-Over section of this chapter.
For more information on parameters, refer to the Crypto Map ISAKMP Configuration Mode Commands chapter in the Command Line Interface Reference.
Verifying the ISAKMP Crypto Map Configuration
These instructions are used to verify the ISAKMP crypto map configuration.
Step 1
show crypto map [ tag map_name | type ipsec-isakmp ]
This command produces an output similar to that displayed below that displays the configuration of a crypto map named test_map2.
Map Name : test_map2
========================================
Payload :
crypto_acl2: permit tcp host 10.10.2.12 neq 35 any
Crypto map Type : ISAKMP
IKE Mode : MAIN
IKE pre-shared key : 3fd32rf09svc
Perfect Forward Secrecy : Group2
Hard Lifetime :
28800 seconds
4608000 kilobytes
Number of Transforms: 1
Transform : test1
AH : none
ESP: md5 3des-cbc
Encaps mode: TUNNEL
Local Gateway: Not Set
Remote Gateway: 192.168.1.1
Caution: Modification(s) to an existing ISAKMP crypto map configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
Dynamic Crypto Map Configuration
This section provides instructions for configuring dynamic crypto maps. Dynamic crypto maps should only be configured in support of L2TP or Mobile IP applications.
Important: This section provides the minimum instruction set for configuring dynamic crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Map Dynamic Configuration Mode chapters in the Command Line Interface Reference.
To configure the dynamic crypto maps for IPSec:
Step 1
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring Dynamic Crypto Maps
Use the following example to create the crypto transform set on your system:
configure
  context <ctxt_name>
     crypto map <map_name> ipsec-dynamic
        set pfs { group1 | group2 | group5 }
        set transform-set <transform_name>
        end
Notes:
<ctxt_name> is the system context in which you wish to create and configure the dynamic crypto maps.
<map_name> is name by which the dynamic crypto map will be recognized by the system.
For more information on parameters, refer to the Crypto Map Dynamic Configuration Mode Commands chapter in the Command Line Interface Reference.
Verifying the Dynamic Crypto Map Configuration
These instructions are used to verify the dynamic crypto map configuration.
Step 1
show crypto map [ tag map_name | type ipsec-dynamic ]
This command produces an output similar to that displayed below using the configuration of a dynamic crypto map named test_map3.
Map Name : test_map3
========================================
Crypto map Type : ISAKMP (Dynamic)
IKE Mode : MAIN
IKE pre-shared key :
Perfect Forward Secrecy : Group2
Hard Lifetime :
28800 seconds
4608000 kilobytes
Number of Transforms: 1
Transform : test1
AH : none
ESP: md5 3des-cbc
Encaps mode: TUNNEL
Local Gateway: Not Set
Remote Gateway: Not Set
Caution: Modification(s) to an existing dynamic crypto map configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
Manual Crypto Map Configuration
This section provides instructions for configuring manual crypto maps on the system.
Important: Because manual crypto map configurations require the use of static security keys (associations), they are not as secure as crypto maps that rely on dynamically configured keys. Therefore, it is recommended that they only be configured and used for testing purposes.
Important: This section provides the minimum instruction set for configuring manual crypto maps on the system. For more information on commands that configure additional parameters and options, refer to the Context Configuration Mode Commands and Crypto Map Manual Configuration Mode chapters in the Command Line Interface Reference.
To configure the manual crypto maps for IPSec:
Step 1
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring Manual Crypto Maps
Use the following example to create the manual crypto map on your system:
configure
  context <ctxt_name>
     crypto map <map_name> ipsec-manual
        set peer <agw_address>
        match address <acl_name> [ preference ]
        set transform-set <transform_name>
        set session-key { inbound | outbound } { ah <ah_spi> [ encrypted ] key <ah_key> | esp <esp_spi> [ encrypted ] cipher <encryption_key> [ encrypted ] authenticator <auth_key> }
        end
Notes:
<ctxt_name> is the system context in which you wish to create and configure the manual crypto maps.
<map_name> is name by which the manual crypto map will be recognized by the system.
<acl_name> is name of the pre-configured ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. This is an optional parameter.
<group_name> is name of the Crypto group configured in the same context. It is used for configurations using the IPSec Tunnel Failover feature. This is an optional parameter.
For more information on parameters, refer to the Crypto Map Manual Configuration Mode Commands chapter in the Command Line Interface Reference.
Verifying the Manual Crypto Map Configuration
These instructions are used to verify the manual crypto map configuration.
Step 1
show crypto map [ tag map_name | type ipsec-manual ]
This command produces an output similar to that displayed below that displays the configuration of a crypto map named test_map.
Map Name : test_map
========================================
Payload :
crypto_acl1: permit tcp host 1.2.3.4 gt 30 any
Crypto map Type : manual(static)
Transform : test1
Encaps mode: TUNNEL
Transmit Flow
Protocol : ESP
SPI : 0x102 (258)
Hmac : md5, key: 23d32d23cs89
Cipher : 3des-cbc, key: 1234asd3c3d
Receive Flow
Protocol : ESP
SPI : 0x101 (257) Hmac : md5, key: 008j90u3rjp
Cipher : 3des-cbc, key: sdfsdfasdf342d32
Local Gateway: Not Set
Remote Gateway: 192.168.1.40
Caution: Modification(s) to an existing manual crypto map configuration will not take effect until the related security association has been cleared. Refer to the clear crypto security-association command located in the Exec Mode Commands chapter of the Command Line Interface Reference for more information.
Crypto Map and Interface Association
This section provides instructions for applying manual or ISAKMP crypto maps to interfaces configured on the system. Dynamic crypto maps should not be applied to interfaces.
Important: This section provides the minimum instruction set for applying manual or ISAKMP crypto maps to an interface on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
To apply the crypto maps to an interface:
Step 1
Step 2
Step 3
Step 4
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Applying Crypto Map to an Interface
Use the following example to apply an existing crypto map to an interface on your system:
configure
  context <ctxt_name>
     interface <interface_name>
     crypto-map <map_name>
     end
Notes:
<ctxt_name> is the system context in which the interface is configured to apply crypto map.
<interface_name> is the name of a specific interface configured in the context to which the crypto map will be applied.
<map_name> is name of the preconfigured ISAKMP or a manual crypto map.
Verifying the Interface Configuration with Crypto Map
These instructions are used to verify the interface configuration with crypto map.
Step 1
show configuration context ctxt_name | grep interface
The interface configuration aspect of the display should look similar to that shown below. In this example an interface named 20/6 was configured with a crypto map called isakmp_map1.
interface 20/6
ip address 192.168.4.10 255.255.255.0
      crypto-map isakmp_map1
FA Services Configuration to Support IPSec
This section provides instructions for configuring FA services to support IPSec.
These instructions assume that the FA service was previously configured and system is ready to serve as an FA.
Important: This section provides the minimum instruction set for configuring an FA service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
To configure the FA service to support IPSec:
Step 1
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Modifying FA service to Support IPSec
Use the following example to modify FA service to support IPSec on your system:
configure
  context <ctxt_name>
     fa-service <fa_svc_name>
        isakmp peer-ha <ha_address> crypto-map <map_name> [ secret <preshared_secret> ]
        isakmp default crypto-map <map_name> [ secret <preshared_secret> ]
        end
Notes:
<ctxt_name> is the system context in which the FA service is configured to support IPSec.
<fa_svc_name> is name of the FA service for which you are configuring IPSec.
<ha_address> is IP address of the HA service to which FA service will communicate on IPSec.
<map_name> is name of the preconfigured ISAKMP or a manual crypto map.
Verifying the FA Service Configuration with IPSec
These instructions are used to verify the FA service to support IPSec.
Step 1
show fa-service { name service_name | all }
The output of this command is a concise listing of FA service parameter settings configured on the system.
HA Service Configuration to Support IPSec
This section provides instructions for configuring HA services to support IPSec.
These instructions assume that the HA service was previously configured and system is ready to serve as an HA.
Important: This section provides the minimum instruction set for configuring an HA service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
To configure the HA service to support IPSec:
Step 1
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Modifying HA service to Support IPSec
Use the following example to modify an existing HA service to support IPSec on your system:
configure
  context <ctxt_name>
     ha-service <ha_svc_name>
        isakmp aaa-context <aaa_ctxt_name>
        isakmp peer-fa <fa_address> crypto-map <map_name> [ secret <preshared_secret> ]
        end
Notes:
<ctxt_name> is the system context in which the FA service is configured to support IPSec.
<ha_svc_name> is name of the HA service for which you are configuring IPSec.
<fa_address> is IP address of the FA service to which HA service will communicate on IPSec.
<aaa_ctxt_name> name of the context through which the HA service accesses the HAAA server to fetch the IKE S Key and S Lifetime parameters.
<map_name> is name of the preconfigured ISAKMP or a manual crypot map.
Verifying the HA Service Configuration with IPSec
These instructions are used to verify the HA service to support IPSec.
Step 1
show ha-service { name service_name | all }
The output of this command is a concise listing of HA service parameter settings configured on the system.
RADIUS Attributes for IPSec-based Mobile IP Applications
As described in the How the IPSec-based Mobile IP Configuration Works section of this chapter, the system uses attributes stored in a subscriber’s RADIUS profile to determine how IPSec should be implemented.
The table below lists the attributes that must be configured in the subscriber’s RADIUS attributes to support IPSec for Mobile IP. These attributes are contained in the following dictionaries:
Attributes Used for Mobile IP IPSec Support
3 : Enables IPSec for tunnels and registration messages
4 : Disables IPSec
LAC Service Configuration to Support IPSec
This section provides instructions for configuring LAC services to support IPSec.
Important: These instructions are required for compulsory tunneling. They should only be performed for attribute-based tunneling if the Tunnel-Service-Endpoint, the SN1-Tunnel-ISAKMP-Crypto-Map, or the SN1 -Tunnel-ISAKMP-Secret are not configured in the subscriber profile.
These instructions assume that the LAC service was previously configured and system is ready to serve as an LAC server.
Important: This section provides the minimum instruction set for configuring an LAC service to support IPSec on the system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
To configure the LAC service to support IPSec:
Step 1
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Modifying LAC service to Support IPSec
Use the following example to modify an existing LAC service to support IPSec on your system:
configure
  context <ctxt_name>
     lac-service <lac_svc_name>
        peer-lns <ip_address> [encrypted] secret <secret> [crypto-map <map_name> { [encrypted] isakmp-secret <secret> } ] [ description <text> ] [ preference <integer>]
        isakmp aaa-context <aaa_ctxt_name>
        isakmp peer-fa <fa_address> crypto-map <map_name> [ secret <preshared_secret> ]
        end
Notes:
<ctxt_name> is the destination context where the LAC service is configured to support IPSec.
<lac_svc_name> is name of the LAC service for which you are configuring IPSec.
<lns_address> is IP address of the LNS node to which LAC service will communicate on IPSec.
<aaa_ctxt_name> name of the context through which the HA service accesses the HAAA server to fetch the IKE S Key and S Lifetime parameters.
<map_name> is name of the preconfigured ISAKMP or a manual crypot map.
Verifying the LAC Service Configuration with IPSec
These instructions are used to verify the LAC service to support IPSec.
Step 1
show lac-service nameservice_name
The output of this command is a concise listing of LAC service parameter settings configured on the system.
Subscriber Attributes for L2TP Application IPSec Support
In addition to the subscriber profile attributes listed in the RADIUS and Subscriber Profile Attributes Used section of the L2TP Access Concentrator chapter in this guide, the table below lists the attributes required to support IPSec for use with attribute-based L2TP tunneling.
These attributes are contained in the following dictionaries:
Subscriber Attributes for IPSec encrypted L2TP Support
PDSN Service Configuration for L2TP Support
PDSN service configuration is required for compulsory tunneling and optional for attribute-based tunneling.
For attribute-based tunneling, a configuration error could occur such that upon successful authentication, the system determines that the subscriber session requires L2TP but can not determine the name of the context in which the appropriate LAC service is configured from the attributes supplied. As a precautionary, a parameter has been added to the PDSN service configuration options that will dictate the name of the context to use. It is strongly recommended that this parameter be configured.
This section contains instructions for modifying the PDSN service configuration for either compulsory or attribute-based tunneling.
These instructions assume that the PDSN service was previously configured and system is ready to serve as a PDSN.
This section provides the minimum instruction set for configuring an L2TP service on the PDSN system. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference.
To configure the PDSN service to support L2TP:
Step 1
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Modifying PDSN service to Support Attribute-based L2TP Tunneling
Use the following example to modify an existing PDSN service to support attribute-based L2TP tunneling on your system:
configure
  context <ctxt_name>
     pdsn-service <pdsn_svc_name>
        ppp tunnel-context <lac_ctxt_name>
        end
Notes:
<ctxt_name> is the destination context where the PDSN service is configured.
<pdsn_svc_name> is name of the PDSN service for which you are configuring attribute-based L2TP tunneling.
<lac_ctxt_name> is the name of the destination context where the LAC service is located.
Modifying PDSN service to Support Compulsory L2TP Tunneling
Use the following example to modify an existing PDSN service to support compulsory L2TP tunneling on your system:
configure
  context <ctxt_name>
     pdsn-service <pdsn_svc_name>
        ppp tunnel-context <lac_ctxt_name>
        ppp tunnel-type l2tp
        end
Notes:
<ctxt_name> is the destination context where the PDSN service is configured.
<pdsn_svc_name> is name of the PDSN service for which you are configuring attribute-based L2TP tunneling.
<lac_ctxt_name> is name of the destination context where the LAC service is located.
Verifying the PDSN Service Configuration for L2TP
These instructions are used to verify the PDSN service to support L2TP.
Step 1
show pdsn-service name service_name
The output of this command is a concise listing of PDSN service parameter settings configured on the system.
Redundant IPSec Tunnel Fail-Over
The Redundant IPSec Tunnel Fail-Over functionality is included with the IPSec feature license and allows the configuration of a secondary ISAKMP crypto map-based IPSec tunnel over which traffic is routed in the event that the primary ISAKMP crypto map-based tunnel cannot be used.
This feature introduces the concept of crypto (tunnel) groups when using IPSec tunnels for access to packet data networks (PDNs). A crypto group consists of two configured ISAKMP crypto maps. Each crypto map defines the IPSec policy for a tunnel. In the crypto group, one tunnel serves as the primary, the other as the secondary (redundant). Note that the method in which the system determines to encrypt user data in an IPSec tunnel remains unchanged.
Group tunnels are perpetually maintained with IPSec Dead Peer Detection (DPD) packets exchanged with the peer security gateway.
Important: The peer security gateway must support RFC 3706 in order for this functionality to function properly.
When the system determines that incoming user data traffic must be routed over one of the tunnels in a group, the system automatically uses the primary tunnel until either the peer is unreachable (the IPSec DPD packets cease), or the IPSec tunnel fails to re-key. If the primary peer becomes unreachable, the system automatically begins to switch user traffic to the secondary tunnel. The system can be configured to either automatically switch user traffic back to the primary tunnel once the corresponding peer security gateway is reachable and the tunnel is configured, or require manual intervention to do so.
This functionality also supports the generation of Simple network Management Protocol (SNMP) notifications indicating the following conditions:
Primary Tunnel is down: A primary tunnel that was previously "up" is now "down" representing an error condition.
Primary Tunnel is up: A primary tunnel that was previously "down" is now "up".
Secondary tunnel is down: A secondary tunnel that was previously "up" is now "down" representing an error condition.
Secondary Tunnel is up: A secondary tunnel that was previously "down" is now "up".
Fail-over successful: The switchover of user traffic was successful. This is generated for both primary-to-secondary and secondary-to-primary switchovers.
Unsuccessful fail-over: An error occurred when switching user traffic from either the primary to secondary tunnel or the secondary to primary tunnel.
Supported Standards
Support for the following standards and requests for comments (RFCs) has been added with the Redundant IPSec Tunnel Fail-over functionality:
Redundant IPSec Tunnel Fail-over Configuration
This section provides information and instructions for configuring the Redundant IPSec Tunnel Fail-over feature. These instructions assume that the system was previously configured to support subscriber data sessions either as a core service or an HA.
Important: Parameters configured using this procedure must be configured in the same context on the system.
Important: The system supports a maximum of 32 crypto groups per context. However, configuring crypto groups to use the same loopback interface for secondary IPSec tunnels is not recommended and may compromise redundancy on the chassis.
Important: This section provides the minimum instruction set for configuring crypto groups on the system. For more information on commands that configure additional parameters and options, refer Command Line Interface Reference.
To configure the Crypto group to support IPSec:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring Crypto Group
Use the following example to configure a crypto group on your system for redundant IPSec tunnel fail-over support:
configure
  context <ctxt_name>
     ikev1 keepalive dpd interval <dur> timeout <dur> num-retry <retries>
     crypto-group <group_name>
        match address <acl_name> [ <preference> ]
        switchover auto [ do-not-revert ]
        end
Notes:
<ctxt_name> is the destination context where the Crypto Group is to be configured.
<group_name> is name of the Crypto group you want to configure for IPSec tunnel failover support.
<acl_name> is name of the pre-configured crypto ACL. It is used for configurations not implementing the IPSec Tunnel Failover feature and match the crypto map to a previously defined crypto ACL. For more information on crypto ACL, refer Crypto Access Control List (ACL) section of this chapter.
Modify ISAKMP Crypto Map Configuration to Match Crypto Group
Use the following example to match the crypto group with ISAKMP crypto map on your system:
configure
  context <ctxt_name>
     crypto map <map_name1> ipsec-isakmp
        match crypto-group <group_name> primary
        end
configure
  context <ctxt_name>
     crypto map <map_name> ipsec-isakmp
        match crypto-group <group_name> secondary
        end
Notes:
<ctxt_name> is the system context in which you wish to create and configure the ISAKMP crypto maps.
<group_name> is name of the Crypto group configured in the same context for IPSec Tunnel Failover feature.
<map_name1> is name of the preconfigured ISAKMP crypto map to match with crypto group as primary.
<map_name2> is name of the preconfigured ISAKMP crypto map to match with crypto group as secondary.
Verifying the Crypto Group Configuration
These instructions are used to verify the crypto group configuration.
Step 1
show crypto group [ summary | name group_name ]
The output of this command is a concise listing of crypto group parameter settings configured on the system.
Dead Peer Detection (DPD) Configuration
This section provides instructions for configuring the Dead Peer Detection (DPD).
Defined by RFC 3706, Dead Peer Detection (DPD) is used to simplify the messaging required to verify communication between peers and tunnel availability.
DPD is configured at the context level and is used in support of the IPSec Tunnel Failover feature (refer to the Redundant IPSec Tunnel Fail-Over section) and/or to help prevent tunnel state mismatches between an FA and HA when IPSec is used for Mobile IP applications. When used with Mobile IP applications, DPD ensures the availability of tunnels between the FA and HA. (Note that the starIPSECDynTunUp and starIPSECDynTunDown SNMP traps are triggered to indicate tunnel state for the Mobile IP scenario.)
Regardless of the application, DPD must be supported/configured on both security peers. If the system is configured with DPD but it is communicating with a peer that does not have DPD configured, IPSec tunnels still come up. However, the only indication that the remote peer does not support DPD exists in the output of the show crypto isakmp security-associations summary command.
Important: If DPD is enabled while IPSec tunnels are up, it will not take affect until all of the tunnels are cleared.
Important: DPD must be configured in the same context on the system as other IPSec Parameters.
To configure the Crypto group to support IPSec:
Step 1
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring Crypto Group
Use the following example to configure a crypto group on your system for redundant IPSec tunnel fail-over support:
configure
  context <ctxt_name>
     ikev1 keepalive dpd interval <dur> timeout <dur> num-retry <retries>
     end
Notes:
<ctxt_name> is the destination context where the Crypto Group is to be configured.
Verifying the DPD Configuration
These instructions are used to verify the dead peer detection configuration.
Step 1
sshow crypto group [ summary | name group_name ]
The output of this command is a concise listing of crypto group parameter settings configured on the system.
APN Template Configuration to Support L2TP
This section provides instructions for adding L2TP support for APN templates configured on the system.
These instructions assume that the APN template was previously configured on this system.
Important: This section provides the minimum instruction set for configuring an APN template to support L2TP for APN. For more information on commands that configure additional parameters and options, refer to the Command Line Interface Reference. To configure the APN to support L2TP:
Step 1
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Modifying APN Template to Support L2TP
Use the following example to modify APN template to support L2TP:
configure
  context <ctxt_name>
     apn <apn_name>
        tunnel l2tp [ peer-address <lns_address> [ [ encrypted ] secret <l2tp_secret> ] [ preference <num> ] [ tunnel-context <tunnel_ctxt_name> ] [ local-address <agw_ip_address> ] [ crypto-map <map_name> { [ encrypted ] isakmp-secret <crypto_secret> } ]
        end
Notes:
<ctxt_name> is the system context in which the APN template is configured.
<apn_name> is name of the preconfigured APN template in which you want to configure L2TP support.
<lns_address> is IP address of the LNS node to which this APN will communicate.
<tunnel_ctxt_name> is the L2TP context in which the L2TP tunnel is configured.
<agw_ip_address> is the local IP address of the GGSN in which this APN template is configured.
<map_name> is the preconfigured crypto map (ISAKMP or manual) which is to use for L2TP.
Verifying the APN Configuration for L2TP
These instructions are used to verify the APN template configuration for L2TP.
Step 1
show apn { all | name apn_name }
The output of this command is a concise listing of FA service parameter settings configured on the system.
IPSec for LTE/SAE Networks
The Cisco MME (Mobility Management Entity), S-GW (Serving Gateway), and P-GW (Packet Data Network Gateway) support IPSec and IKEv2 encryption using IPv4 and IPv6 addressing in LTE/SAE (Long Term Evolution/System Architecture Evolution) networks. IPSec and IKEv2 encryption enables network domain security for all IP packet-switched networks, providing confidentiality, integrity, authentication, and anti-replay protection via secure IPSec tunnels.
Encryption Algorithms
IPSec for LTE/SAE supports the following control and data path encryption algorithms:
HMAC Functions
IPSec for LTE/SAE supports the following data path HMAC (Hash-based Message Authentication Code) functions:
IPSec for LTE/SAE supports the following control path HMAC (Hash-based Message Authentication Code) functions:
Diffie-Hellman Groups
IPSec for LTE/SAE supports the following Diffie-Hellman groups for IKE and Child SAs (Security Associations):
Dynamic Node-to-Node IPSec Tunnels
IPSec for LTE/SAE enables network nodes to initiate an IPSec tunnel with another node for secure signaling and data traffic between the nodes, enabling up to 64K dynamic, service-integrated IPSec tunnels per chassis. Once established, a dynamic node-to-node IPSec tunnel continues to carry all of the signaling and/or bearer traffic between the nodes. Dynamic node-to-node IPSec for LTE/SAE is supported on the S1-MME interface for signaling traffic between the eNodeB and the MME, on the S1-U interface for data traffic between the eNodeB and the S-GW, and on the S5 interface for data traffic between the S-GW and the P-GW.
Dynamic node-to-node IPSec gets configured using dynamic IKEv2 crypto templates, which are used to specify common cryptographic parameters for the IPSec tunnels such as the encryption algorithm, HMAC function, and Diffie-Hellman group. Additional information necessary for creating node-to-node IPSec tunnels such as revocation lists are fetched dynamically from the IPSec tunnel requests.
For configuration instructions for dynamic node-to-node IPSec, see the configuration chapter in the administration guides for the MME, S-GW, and P-GW.
ACL-based Node-to-Node IPSec Tunnels
Node-to-node IPSec for LTE/SAE can also be configured using crypto ACLs (Access Control Lists), which define the matching criteria used for routing subscriber data packets over an IPSec tunnel. ACL-based node-to-node IPSec tunnels are supported on the S1-MME interface for signaling traffic between the eNodeB and the MME, on the S1-U interface for data traffic between the eNodeB and the S-GW, and on the S5 interface for data traffic between the S-GW and the P-GW.
Unlike other ACLs that are applied to interfaces, contexts, or to one or more subscribers, crypto ACLs are applied via matching criteria to crypto maps, which define tunnel policies that determine how IPSec is implemented for subscriber data packets. Prior to routing, the system examines the properties of each subscriber data packet. If the packet properties match the criteria specified in the crypto ACL, the system initiates the IPSec policy dictated by the crypto map. ACL-based node-to-node IPSec tunnels are configured using either IKEv2-IPv4 or IKEv2-IPv6 crypto maps for IPv4 or IPv6 addressing.
Up to 150 ACL-based node-to-node IPSec tunnels are supported on the system, each with one SA bundle that includes one Tx and one Rx endpoint. However, to avoid significant performance degradation, dynamic node-to-node IPSec tunnels are recommended. If ACL-based node-to-node IPSec tunnels are used, a limit of about ten ACL-based node-to-node IPSec tunnels per system is recommended.
For configuration instructions for ACL-based node-to-node IPSec, see the configuration chapter in the administration guides for the MME, S-GW, and P-GW.
For more information on ACLs, see the System Administration Guide.
Traffic Selectors
Per RFC 4306, when a packet arrives at an IPSec subsystem and matches a 'protect' selector in its Security Policy Database (SPD), the subsystem must protect the packet via IPSec tunneling. Traffic selectors enable an IPSec subsystem to accomplish this by allowing two endpoints to share information from their SPDs. Traffic selector payloads contain the selection criteria for packets being sent over IPSec security associations (SAs). Traffic selectors can be created on the P-GW, S-GW, and MME for dynamic node-to-node IPSec tunnels during crypto template configuration by specifying a range of peer IPv4 or IPV6 addresses from which to carry traffic over IPSec tunnels.
For example, consider an eNodeB with an IP address of 1.1.1.1 and an S-GW with a service address of 2.2.2.2. The S-GW is registered to listen for IKE requests from the eNodeBs in the network using the following information:
When an IKE request arrives the S-GW from eNodeB address 1.1.1.1, the IPSec subsystem converts the payload ACL to: udp host 2.2.2.2 eq 2123 host 1.1.1.1, and this payload becomes the traffic selector for the IPSec tunnel being negotiated.
To properly accommodate control traffic between IPSec nodes, each child SA must include at least two traffic selectors: one with a well-known port in the source address, and one with a well-known port in the destination address. Continuing the example above, the final traffic selectors would be:
Note that for ACL-based node-to-node IPSec tunnels, the configured crypto ACL becomes the traffic selector with no modification.
Authentication Methods
IPSec for LTE/SAE includes the following authentication methods:
PSK (Pre-Shared Key) Authentication: A pre-shared key is a shared secret that was previously shared between two network nodes. IPSec for LTE/SAE supports PSK such that both IPSec nodes must be configured to use the same shared secret.
X.509 Certificate-based Peer Authentication: IPSec for LTE/SAE supports X.509 certificate-based peer authentication and CA (Certificate Authority) certificate authentication as described below.
X.509 Certificate-based Peer Authentication
X.509 specifies standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm. X.509 certificates are configured on each IPSec node so that it can send the certificate as part of its IKE_AUTH_REQ for the remote node to authenticate it. These certificates can be in PEM (Privacy Enhanced Mail) or DER (Distinguished Encoding Rules) format, and can be fetched from a repository via HTTP or FTP.
CA certificate authentication is used to validate the certificate that the local node receives from a remote node during an IKE_AUTH exchange.
A maximum of sixteen certificates and sixteen CA certificates are supported per system. One certificate is supported per service, and a maximum of four CA certificates can be bound to one crypto template.
For configuration instructions for X.509 certificate-based peer authentication, see the configuration chapter in the administration guides for the MME, S-GW, and P-GW.
The figure below shows the message flow during X.509 certificate-based peer authentication. The table that follows the figure describes each step in the message flow.
X.509 Certificate-based Peer Authentication
X.509 Certificate-based Peer Authentication
Certificate Revocation Lists
Certificate revocation lists track certificates that have been revoked by the CA (Certificate Authority) and are no longer valid. Per RFC 3280, during certificate validation, IPSec for LTE/SAE checks the certificate revocation list to verify that the certificate the local node receives from the remote node has not expired and hence is still valid.
During configuration via the system CLI, one certificate revocation list is bound to each crypto template and can be fetched from its repository via HTTP or FTP.
Child SA Rekey Support
Rekeying of an IKEv2 Child Security Association (SA) occurs for an already established Child SA whose lifetime (either time-based or data-based) is about to exceed a maximum limit. The IPSec subsystem initiates rekeying to replace the existing Child SA. During rekeying, two Child SAs exist momentarily (500ms or less) to ensure that transient packets from the original Child SA are processed by the IPSec node and not dropped.
Child SA rekeying is disabled by default, and rekey requests are ignored. This feature gets enabled in the Crypto Configuration Payload Mode of the system’s CLI.
IKEv2 Keep-Alive Messages (Dead Peer Detection)
IPSec for LTE/SAE supports IKEv2 keep-alive messages, also known as Dead Peer Detection (DPD), originating from both ends of an IPSec tunnel. Per RFC 3706, DPD is used to simplify the messaging required to verify communication between peers and tunnel availability. You configure DPD on each IPSec node. You can also disable DPD, and the node will not initiate DPD exchanges with other nodes. However, the node always responds to DPD availability checks initiated by another node regardless of its DPD configuration.
E-UTRAN/EPC Logical Network Interfaces Supporting IPSec Tunnels
The figure below shows the logical network interfaces over which secure IPSec tunnels can be created in an E-UTRAN/EPC (Evolved UMTS Terrestrial Radio Access Network/Evolved Packet Core) network. The table that follows the figure provides a description of each logical network interface.
E-UTRAN/EPC Logical Network Interfaces Supporting IPSec Tunnels
E-UTRAN/EPC Logical Network Interfaces Supporting IPSec Tunnels
IPSec Tunnel Termination
IPSec tunnel termination occurs during the following scenarios:
Idle Tunnel Termination: When a session manager for a service detects that all subscriber sessions using a given IPSec tunnel have terminated, the IPSec tunnel also gets terminated after a timeout period.
Service Termination: When a service running on a network node is brought down for any reason, all corresponding IPSec tunnels get terminated. This may be caused by the interface for a service going down, a service being stopped manually, or a task handling an IPSec tunnel restarting.
Unreachable Peer: If a network node detects an unreachable peer via Dead Peer Detection (DPD), the IPSec tunnel between the nodes gets terminated. DPD can be enabled per P-GW, S-GW, and MME service via the system CLI during crypto template configuration.
E-UTRAN Handover Handling: Any IPSec tunnel that becomes unusable due to an E-UTRAN network handover gets terminated, while the network node to which the session is handed initiates a new IPSec tunnel for the session.
 
 
Appendix G
L2TP Access Concentrator
 
This chapter describes the Layer 2 Tunneling Protocol (L2TP) Access Concentrator (LAC) functionality support on Cisco® ASR 5x00 chassis and explains how it is configured.
The product Administration Guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in the respective product Administration Guide, before using the procedures in this chapter.
Important: The L2TP Access Concentrator is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
When enabled though the session license and feature use key, the system supports L2TP for encapsulation of data packets between it and one or more L2TP Network Server (LNS) nodes. In the system, this optional packet encapsulation, or tunneling, is performed by configuring L2TP Access Concentrator (LAC) services within contexts.
Important: The LAC service uses UDP ports 13660 through 13668 as the source port for sending packets to the LNS.
Applicable Products and Relevant Sections
The LAC feature is supported for various products. The following table indicates the products on which the feature is supported and the relevant sections within the chapter that pertain to that product.
Supported LAC Service Configurations for PDSN Simple IP
LAC services can be applied to incoming PPP sessions using one of the following methods:
Attribute-based tunneling: This method is used to encapsulate PPP packets for only specific users, identified during authentication. In this method, the LAC service parameters and allowed LNS nodes that may be communicated with are controlled by the user profile for the particular subscriber. The user profile can be configured locally on the system or remotely on a RADIUS server.
PDSN Service-based compulsory tunneling: This method of tunneling is used to encapsulate all incoming PPP traffic from the R-P interface coming into a PDSN service, and tunnel it to an LNS peer for authentication. It should be noted that this method does not consider subscriber configurations, since all authentication is performed by the peer LNS.
Each LAC service is bound to a single system interface configured within the same system context. It is recommended that this context be a destination context as displayed in the following figure.
LAC Service Configuration for SIP
Attribute-based Tunneling
This section describes the working of attribute-based tunneling and its configuration.
How The Attribute-based L2TP Configuration Works
The following figure and the text that follows describe how Attribute-based tunneling is performed using the system.
Attribute-based L2TP Session Processing for SIP
1.
2.
3.
4.
5.
6.
Configuring Attribute-based L2TP Support for PDSN Simple IP
This section provides a list of the steps required to configure attribute-based L2TP support for use with PDSN Simple IP applications. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a PDSN.
Step 1
Configure the subscriber profiles according to the information and instructions located in the Configuring Subscriber Profiles for L2TP Support section of this chapter.
Step 2
Step 3
Step 4
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
PDSN Service-based Compulsory Tunneling
This section describes the working of service-based compulsory tunneling and its configuration.
How PDSN Service-based Compulsory Tunneling Works
PDSN Service-based compulsory tunneling enables wireless operators to send all PPP traffic to remote LNS peers over an L2TP tunnel for authentication. This means that no PPP authentication is performed by the system.
Accounting start and interim accounting records are still sent to the local RADIUS server configured in the system’s AAA Service configuration. When the L2TP session setup is complete, the system starts its call counters and signals the RADIUS server to begin accounting. The subscriber name for accounting records is based on the NAI-constructed name created for each session.
PDSN service-based compulsory tunneling requires the modification of one or more PDSN services and the configuration of one or more LAC services.
The following figure and the text that follows describe how PDSN service-based compulsory tunneling is performed using the system.
PDSN Service-based Compulsory Tunneling Session Processing
1.
2.
The PDSN service detects its tunnel-type parameter is configured to L2TP and its tunnel-context parameter is configured to the Destination context.
3.
4.
5.
6.
7.
Session data traffic is passed over the L2TP tunnel established in step 4.
Configuring L2TP Compulsory Tunneling Support for PDSN Simple IP
This section provides a list of the steps required to configure L2TP compulsory tunneling support for use with PDSN Simple IP applications. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a PDSN.
Step 1
Step 2
Configure the PDSN service(s) according to the instructions located in the Modifying PDSN Services for L2TP Support section of this chapter.
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Supported LAC Service Configurations for the GGSN and P-GW
As mentioned previously, L2TP is supported through the configuration of LAC services on the system. Each LAC service is bound to a single system interface configured within the same system destination context as displayed in following figure.
GGSN LAC Service Configuration
LAC services are applied to incoming subscriber PDP contexts based on the configuration of attributes either in the GGSN/’s Access Point Name (APN) templates or in the subscriber’s profile. Subscriber profiles can be configured locally on the system or remotely on a RADIUS server.
LAC service also supports domain-based L2TP tunneling with LNS. This method is used to create multiple tunnels between LAC and LNS on the basis of values received in “Tunnel-Client-Auth-ID” or “Tunnel-Server-Auth-ID” attribute received from AAA Server in Access-Accept as a key for tunnel selection and creation. When the LAC needs to establish a new L2TP session, it first checks if there is any existing L2TP tunnel with the peer LNS based on the value of key “Tunnel-Client-Auth-ID” or “Tunnel-Server-Auth-ID” attribute. If no such tunnel exists for the key, it will create a new Tunnel with the LNS.
If LAC service needs to establish a new tunnel for new L2TP session with LNS and the tunnel create request fails because maximum tunnel creation limit is reached, LAC will try other LNS addresses received from AAA server in Access-Accept message. If all available peer-LNS are exhausted, LAC service will reject the call
L2TP tunnel parameters are configured within the APN template and are applied to all subscribers accessing the APN. However, L2TP operation will differ depending on the subscriber’s PDP context type as described below:
Transparent IP: The APN template’s L2TP parameter settings will be applied to the session.
Non-transparent IP: Since authentication is required, L2TP parameter attributes in the subscriber profile (if configured) will take precedence over the settings in the APN template.
PPP: The APN template’s L2TP parameter settings will be applied and all of the subscriber’s PPP packets will be forwarded to the specified LNS.
More detailed information is located in the sections that follow.
Transparent IP PDP Context Processing with L2TP Support
The following figure and the text that follows describe how transparent IP PDP contexts are processed when L2TP tunneling is enabled.
Transparent IP PDP Context Call Processing with L2TP Tunneling
1.
2.
The APN configuration indicates such things as the IP address of the LNS, the system destination context in which a LAC service is configured, and the outbound username and password that will be used by the LNS to authenticate incoming sessions. If no outbound information is configured, the subscriber’s International Mobile Subscriber Identity (IMSI) is used as the username at the peer LNS.
1.
2.
3.
4.
Non-transparent IP PDP Context Processing with L2TP Support
The following figure and the text that follows describe how non-transparent IP PDP contexts are processed when L2TP tunneling is enabled.
Non-transparent IP PDP Context Call Processing with L2TP Tunneling
1.
2.
The APN configuration indicates such things as the IP address of the LNS, the system destination context in which a LAC service is configured, and the outbound username and password that will be used by the LNS to authenticate incoming sessions. If no outbound information is configured, the subscriber’s username is sent to the peer LNS.
3.
As part of the authentication, the RADIUS server returns an Access-Accept message.
The message may include attributes indicating that session data is to be tunneled using L2TP, and the name and location of the LAC service to use. An attribute could also be provided indicating the LNS peer to connect to.
If these attributes are supplied, they take precedence over those specified in the APN template.
4.
5.
6.
7.
PPP PDP Context Processing with L2TP Support
The following figure and the text that follows describe how non-transparent IP PDP contexts are processed when L2TP tunneling is enabled.
PPP PDP Context Call Processing with L2TP Tunneling
1.
2.
The APN configuration indicates such things as the IP address of the LNS, the system destination context in which a LAC service is configured.
Note that L2TP support could also be configured in the subscriber’s profile. If the APN is not configured for L2TP tunneling, the system will attempt to authenticate the subscriber.The tunneling parameters in the subscriber’s profile would then be used to determine the peer LNS.
3.
4.
5.
6.
Configuring the GGSN or P-GW to Support L2TP
This section provides a list of the steps required to configure the GGSN or P-GW to support L2TP. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a GGSN or P-GW.
1.
Important: L2TP tunneling can be configured within individual subscriber profiles as opposed/or in addition to configuring support with an APN template. Subscriber profile configuration is described in the Configuring Subscriber Profiles for L2TP Support section of this chapter.
2.
3.
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Supported LAC Service Configuration for Mobile IP
LAC services can be applied to incoming MIP sessions using attribute-based tunneling. Attribute-based tunneling is used to encapsulate PPP packets for specific users, identified during authentication. In this method, the LAC service parameters and allowed LNS nodes that may be communicated with are controlled by the user profile for the particular subscriber. The user profile can be configured locally on the system or remotely on a RADIUS server.
Each LAC service is bound to a single system interface within the same system context. It is recommended that this context be a destination context as displayed in figure below.
LAC Service Configuration for MIP
How The Attribute-based L2TP Configuration for MIP Works
The following figure and the text that follows describe how Attribute-based tunneling for MIP is performed using the system.
Attribute-based L2TP Session Processing for MIP
1.
2.
3.
4.
5.
6.
Configuring Attribute-based L2TP Support for HA Mobile IP
This section provides a list of the steps required to configure attribute-based L2TP support for use with HA Mobile IP applications. Each step listed refers to a different section containing the specific instructions for completing the required procedure.
Important: These instructions assume that the system was previously configured to support subscriber data sessions as an HA.
Step 1
Configure the subscriber profiles according to the information and instructions located in the Configuring Subscriber Profiles for L2TP Support section of this chapter.
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring Subscriber Profiles for L2TP Support
This section provides information and instructions on the following procedures:
Important: Since the instructions for configuring subscribers differ between RADIUS server applications, this section only provides the individual attributes that can be added to the subscriber profile. Refer to the documentation that shipped with your RADIUS server for instructions on configuring subscribers.
RADIUS and Subscriber Profile Attributes Used
Attribute-based L2TP tunneling is supported through the use of attributes configured in subscriber profiles stored either locally on the system or remotely on a RADIUS server. The following table describes the attributes used in support of LAC services. These attributes are contained in the standard and VSA dictionaries.
Subscriber Attributes for L2TP Support
Important: If the LAC service and egress interface are configured in the same context as the core service or HA service, this attribute is not needed.
Important: This attribute is only used when the loadbalance-tunnel-peers parameter or SN-Tunnel-Load-Balancing attribute configured to prioritized.
Random - Random LNS selection order, the Tunnel-Preference attribute is not used in determining which LNS to select.
Balanced - LNS selection is sequential balancing the load across all configured LNS nodes, the Tunnel-Preference attribute is not used in determining which LNS to select.
Prioritized - LNS selection is made based on the priority assigned in the Tunnel-Preference attribute.
RADIUS Tagging Support
The system supports RADIUS attribute tagging for tunnel attributes. These “tags” organize together multiple attributes into different groups when multiple LNS nodes are defined in the user profile. Tagging is useful to ensure that the system groups all the attributes used for a specific server. If attribute tagging is not supported by your specific RADIUS server, the system implicitly organizes the attributes in the order that they are listed in the access accept packet.
Configuring Local Subscriber Profiles for L2TP Support
This section provides information and instructions for configuring local subscriber profiles on the system to support L2TP.
Important: The configuration of RADIUS-based subscriber profiles is not discussed in this document. Please refer to the documentation supplied with your RADIUS server for further information.
Important: This section provides the minimum instruction set for configuring local subscriber profile for L2TP support on the system. For more information on commands that configure additional parameters and options, refer to the LAC Service Configuration Mode Commands chapter in the Command Line Interface Reference.
To configure the system to provide L2TP support to subscribers:
Step 1
Step 2
Verify your L2TP configuration by following the steps in the Verifying the L2TP Configuration section.
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring Local Subscriber
Use the following example to configure the Local subscriber with L2TP tunnel parameters. Optionally you can configure load balancing between multiple LNS servers:
configure
  context <ctxt_name> [-noconfirm]
     subscriber name <subs_name>
        tunnel l2tp peer-address <lns_ip_address> [ preference <integer> | [ encrypted ] secret <secret_string> | tunnel-context <context_name> | local-address <local_ip_address> }
        load-balancing { random | balanced | prioritized }
        end
Notes:
<ctxt_name> is the system context in which you wish to configure the subscriber profile.
<lns_ip_address> is the IP address of LNS server node and <local_ip_address> is the IP address of system which is bound to LAC service.
Verifying the L2TP Configuration
These instructions are used to verify the L2TP configuration.
Step 1
show subscriber configuration username user_name
The output of this command is a concise listing of subscriber parameter settings as configured.
Tunneling All Subscribers in a Specific Context Without Using RADIUS Attributes
As with other services supported by the system, values for subscriber profile attributes not returned as part of a RADIUS Access-Accept message can be obtained using the locally configured profile for the subscriber named default. The subscriber profile for default must be configured in the AAA context (i.e. the context in which AAA functionality is configured).
As a time saving feature, L2TP support can be configured for the subscriber named default with no additional configuration for RADIUS-based subscribers. This is especially useful when you have separate source/AAA contexts for specific subscribers.
To configure the profile for the subscriber named default, follow the instructions above for configuring a local subscriber and enter the name default.
Configuring LAC Services
Important: Not all commands, keywords and functions may be available. Functionality is dependent on platform and license(s).
This section provides information and instructions for configuring LAC services on the system allowing it to communicate with peer LNS nodes.
Important: This section provides the minimum instruction set for configuring LAC service support on the system. For more information on commands that configure additional parameters and options, refer to the LAC Service Configuration Mode Commands chapter in the Command Line Interface Reference.
To configure the LAC services on system:
Step 1
Step 2
Optional. Configure LNS peer information if the Tunnel-Service-Endpoint attribute is not configured in the subscriber profile or PDSN compulsory tunneling is supported by applying the example configuration in the Configuring LNS Peer section.
Step 3
Step 4
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring LAC Service
Use the following example to create the LAC service and bind the service to an IP address:
configure
  context <dst_ctxt_name> [-noconfirm]
     lac-service <service_name>
        bind address <ip_address>
        end
Notes:
<dst_ctxt_name> is the destination context where you want to configure the LAC service.
Configuring LNS Peer
Use the following example to configure the LNS peers and load balancing between multiple LNS peers:
configure
   context <dst_ctxt_name> [ -noconfirm ]
     lac-service <service_name>
        tunnel selection-key tunnel-server-auth-id
        peer-lns <ip_address> [encrypted] secret <secret> [crypto-map <map_name> {[encrypted] isakmp-secret <secret> }] [description <text>] [ preference <integer>]
        load-balancing { random | balanced | prioritized }
        end
Notes:
<dst_ctxt_name> is the destination context where the LAC service is configured.
Verifying the LAC Service Configuration
These instructions are used to verify the LAC service configuration.
Step 1
show lac-service name service_name
The output given below is a concise listing of LAC service parameter settings as configured.
Service name: vpn1
Context:                       isp1
Bind:                          Done
Local IP Address:              192.168.2.1
First Retransmission Timeout:  1 (secs)
Max Retransmission Timeout:    8 (secs)
Max Retransmissions:           5
Max Sessions:                  500000      Max Tunnels: 32000
Max Sessions Per Tunnel:       512
Data Sequence Numbers:         Enabled   Tunnel Authentication: Enabled
Keep-alive interval:           60         Control receive window: 16
Max Tunnel Challenge Length:   16
Proxy LCP Authentication:      Enabled
Load Balancing:                Random
Service Status:                Started
Newcall Policy:                None
Modifying PDSN Services for L2TP Support
PDSN service modification is required for compulsory tunneling and optional for attribute-based tunneling.
For attribute-based tunneling, a configuration error could occur such that upon successful authentication, the system determines that the subscriber session requires L2TP but can not determine the name of the context in which the appropriate LAC service is configured from the attributes supplied. As a precautionary, a parameter has been added to the PDSN service configuration options that will dictate the name of the context to use. It is strongly recommended that this parameter be configured.
This section contains instructions for modifying the PDSN service configuration for either compulsory or attribute-based tunneling.
Important: This section provides the minimum instruction set for modifying PDSN service for L2TP support on the system. For more information on commands that configure additional parameters and options, refer to the LAC Service Configuration Mode Commands chapter in the Command Line Interface Reference.
To configure the LAC services on system:
Step 1
Step 2
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Modifying PDSN Service
Use the following example to modify the PDSN service to support L2TP by associating LAC context and defining tunnel type:
configure
  context <source_ctxt_name> [ -noconfirm ]
     pdsn-service <pdsn_service_name>
        ppp tunnel-context <lac_context_name>
        ppp tunnel-type { l2tp | none }
        end
Notes:
<source_ctxt_name> is the name of the source context containing the PDSN service, which you want to modify for L2TP support.
<pdsn_service_name> is the name of the pre-configured PDSN service, which you want to modify for L2TP support.
<lac_context_name> is typically the destination context where the LAC service is configured.
Verifying the PDSN Service for L2TP Support
These instructions are used to verify the PDSN service configuration.
Step 1
show pdsn-service name pdsn_service_name
The output of this command is a concise listing of PDSN service parameter settings as configured.
Modifying APN Templates to Support L2TP
This section provides instructions for adding L2TP support for APN templates configured on the system.
Important: This section provides the minimum instruction set for configuring LAC service support on the system. For more information on commands that configure additional parameters and options, refer to the LAC Service Configuration Mode Commands chapter in the Command Line Interface Reference.
To configure the LAC services on system:
Step 1
Step 2
Step 3
Verify your APN configuration by following the steps in the Verifying the APN Configuration section.
Step 4
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Assigning LNS Peer Address in APN Template
Use following example to assign LNS server address with APN template:
configure
  context <dst_ctxt_name> [-noconfirm]
     apn <apn_name>
        tunnel l2tp [ peer-address <lns_address> [ [ encrypted ] secret <l2tp_secret> ] [ preference <integer> ] [ tunnel-context <l2tp_context_name> ] [ local-address <local_ip_address> ] [ crypto-map <map_name> { [ encrypted ] isakmp-secret <crypto_secret> } ]
        end
Notes:
<dst_ctxt_name> is the name of system destination context in which the APN is configured.
<apn_name> is the name of the pre-configured APN template which you want to modify for the L2TP support.
<lns_address> is the IP address of LNS server node and <local_ip_address> is the IP address of system which is bound to LAC service.
Configuring Outbound Authentication
Use the following example to configure the LNS peers and load balancing between multiple LNS peers:
configure
  context <dst_ctxt_name> [ -noconfirm ]
     apn <apn_name>
        outbound { [ encrypted ] password <pwd> | username <name> }
        end
Notes:
<dst_ctxt_name> is the destination context where APN template is is configured.
<apn_name> is the name of the pre-configured APN template which you want to modify for the L2TP support.
Verifying the APN Configuration
These instructions are used to verify the APN configuration.
Step 1
show apn name apn_name
The output is a concise listing of APN parameter settings as configured.
 
 
Appendix H
Mobile IP Registration Revocation
 
This chapter describes Registration Revocation for Mobile-IP and Proxy Mobile-IP and explains how it is configured. The product administration guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model and configure the required elements for that model, as described in this administration guide before using the procedures in this chapter.
Important: This license is enabled by default; however, not all features are supported on all platforms and other licenses may be required for full functionality as described in this chapter.
Overview
Registration Revocation is a general mechanism whereby either the HA or the FA providing Mobile IP functionality to the same mobile node can notify the other mobility agent of the termination of a binding. This functionality provides the following benefits:
Mobile IP Registration Revocation can be triggered at the FA by any of the following:
Important: Registration Revocation functionality is also supported for Proxy Mobile IP. However, only the HA can initiate the revocation for Proxy-MIP calls.
Mobile IP Registration Revocation can be triggered at the HA by any of the following:
The FA and the HA negotiate Registration Revocation support when establishing a Mobile IP call. Revocation support is indicated to the Mobile Node (MN) from the FA by setting the 'X' bit in the Agent Advertisement to MN. However the MN is not involved in negotiating the Revocation for a call or in the Revocation process. It only gets notified about it. The X bit in the Agent Advertisements is just a hint to the MN that revocation is supported at the FA but is not a guarantee that it can be negotiated with the HA
At the FA, if revocation is enabled and a FA-HA SPI is configured, the Revocation Support extension is appended to the RRQ received from the MN and protected by the FA-HA Authentication Extension. At the HA, if the RRQ is accepted, and the HA supports revocation, the HA responds with an RRP that includes the Revocation Support extension. Revocation support is considered to be negotiated for a binding when both sides have included a Revocation Support Extension during a successful registration exchange.
Important: The Revocation Support Extension in the RRQ or RRP must be protected by the FA-HA Authentication Extension. Therefore, an FA-HA SPI must be configured at the FA and the HA for this to succeed.
If revocation is enabled at the FA, but an FA-HA SPI is not configured at the FA for a certain HA, then FA does not send Revocation Support Extension for a call to that HA. Therefore, the call may come up without Revocation support negotiated.
If the HA receives an RRQ with Revocation Support Extension, but not protected by FA-HA Auth Extension, it will be rejected with “FA Failed Authentication” error.
If the FA receives a RRP with Revocation Support Extension, but not protected by FA-HA Auth Extension, it will be rejected with “HA Failed Authentication” error.
Also note that Revocation support extension is included in the initial, renewal or handoff RRQ/RRP messages. The Revocation extension is not included in a Deregistration RRQ from the FA and the HA will ignore them in any Deregistration RRQs received.
Configuring Registration Revocation
Support for MIP Registration Revocation requires the following configurations:
FA service(s): Registration Revocation must be enabled and operational parameters optionally configured.
HA service(s): Registration Revocation must be enabled and operational parameters optionally configured.
Important: These instructions assume that the system was previously configured to support subscriber data sessions for a core network service with FA and/or an HA according to the instructions described in the respective product Administration Guide.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
Configuring FA Services
Configure FA services to support MIP Registration Revocation by applying the following example configuration:
configure
  context <context_name>
     fa-service <fa_service_name>
        revocation enable
        revocation max-retransmission <number>
        revocation retransmission-timeout <time>
        end
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring HA Services
Configure HA services to support MIP Registration Revocation by applying the following example configuration:
configure
  context <context_name>
     ha-service <ha_service_name>
        revocation enable
        revocation max-retransmission <number>
        revocation retransmission-timeout <time>
        end
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
 
 
Appendix I
Proxy-Mobile IP
 
This chapter describes system support for Proxy Mobile IP and explains how it is configured. The product administration guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model before using the procedures in this chapter.
Proxy Mobile IP provides a mobility solution for subscribers with mobile nodes (MNs) capable of supporting only Simple IP.
This chapter includes the following sections:
Overview
Proxy Mobile IP provides mobility for subscribers with MNs that do not support the Mobile IP protocol stack.
Important: Proxy Mobile IP is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
The Proxy Mobile IP feature is supported for various products. The following table indicates the products on which the feature is supported and the relevant sections within the chapter that pertain to that product.
Applicable Products and Relevant Sections
Proxy Mobile IP in 3GPP2 Service
For subscriber sessions using Proxy Mobile IP, R-P and PPP sessions get established between the MN and the PDSN as they would for a Simple IP session. However, the PDSN/FA performs Mobile IP operations with an HA (identified by information stored in the subscriber’s profile) on behalf of the MN (i.e. the MN is only responsible for maintaining the Simple IP PPP session with PDSN).
The MN is assigned an IP address by either the PDSN/FA or the HA. Regardless of its source, the address is stored in a mobile binding record (MBR) stored on the HA. Therefore, as the MN roams through the service provider’s network, each time a hand-off occurs, the MN will continue to use the same IP address stored in the MBR on the HA.
Note that unlike Mobile IP-capable MNs that can perform multiple sessions over a single PPP link, Proxy Mobile IP allows only a single session over the PPP link. In addition, simultaneous Mobile and Simple IP sessions will not be supported for an MN by the FA that is currently facilitating a Proxy Mobile IP session for the MN.
The MN is assigned an IP address by either the HA, a AAA server, or on a static-basis. The address is stored in a mobile binding record (MBR) stored on the HA. Therefore, as the MN roams through the service provider’s network, each time a hand-off occurs, the MN will continue to use the same IP address stored in the MBR on the HA.
Proxy Mobile IP in 3GPP Service
For IP PDP contexts using Proxy Mobile IP, the MN establishes a session with the GGSN as it normally would. However, the GGSN/FA performs Mobile IP operations with an HA (identified by information stored in the subscriber’s profile) on behalf of the MN (i.e. the MN is only responsible for maintaining the IP PDP context with the GGSN, no Agent Advertisement messages are communicated with the MN).
The MN is assigned an IP address by either the HA, a AAA server, or on a static-basis. The address is stored in a mobile binding record (MBR) stored on the HA. Therefore, as the MN roams through the service provider’s network, each time a hand-off occurs, the MN will continue to use the same IP address stored in the MBR on the HA.
Proxy Mobile IP can be performed on a per-subscriber basis based on information contained in their user profile, or for all subscribers facilitated by a specific APN. In the case of non-transparent IP PDP contexts, attributes returned from the subscriber’s profile take precedence over the configuration of the APN.
Proxy Mobile IP in WiMAX Service
For subscriber sessions using Proxy Mobile subscriber sessions get established between the MN and the ASN GW as they would for a Simple IP session. However, the ASN GW/FA performs Mobile IP operations with an HA (identified by information stored in the subscriber’s profile) on behalf of the MN (i.e. the MN is only responsible for maintaining the Simple IP subscriber session with ASN GW).
The MN is assigned an IP address by either the ASN GW/FA or the HA. Regardless of its source, the address is stored in a mobile binding record (MBR) stored on the HA. Therefore, as the MN roams through the service provider’s network, each time a hand-off occurs, the MN will continue to use the same IP address stored in the MBR on the HA.
Note that unlike Mobile IP-capable MNs that can perform multiple sessions over a single session link, Proxy Mobile IP allows only a single session over the session link. In addition, simultaneous Mobile and Simple IP sessions will not be supported for an MN by the FA that is currently facilitating a Proxy Mobile IP session for the MN.
How Proxy Mobile IP Works in 3GPP2 Network
This section contains call flows displaying successful Proxy Mobile IP session setup scenarios. There are multiple scenarios that are dependant on how the MN receives an IP address. The following scenarios are described:
Scenario 1: The AAA server that authenticates the MN at the PDSN allocates an IP address to the MN. Note that the PDSN does not allocate an address from its IP pools.
Scenario 2: The HA assigns an IP address to the MN from one of its locally configured dynamic pools.
Scenario 1: AAA server and PDSN/FA Allocate IP Address
The following figure and table display and describe a call flow in which the MN receives its IP address from the AAA server and PDSN/FA.
AAA/PDSN Assigned IP Address Proxy Mobile IP Call Flow
AAA/PDSN Assigned IP Address Proxy Mobile IP Call Flow Description
Scenario 2: HA Allocates IP Address
The following figure and table display and describe a call flow in which the MN receives its IP address from the HA.
HA Assigned IP Address Proxy Mobile IP Call Flow
HA Assigned IP Address Proxy Mobile IP Call Flow Description
How Proxy Mobile IP Works in 3GPP Network
This section contains call flows displaying successful Proxy Mobile IP session setup scenarios in 3GPP network.
The following figure and the text that follows describe a a sample successful Proxy Mobile IP session setup call flow in 3GGP service.
Proxy Mobile IP Call Flow in 3GPP
Proxy Mobile IP Call Flow in 3GPP Description
How Proxy Mobile IP Works in WiMAX Network
This section contains call flows displaying successful Proxy Mobile IP session setup scenarios. There are multiple scenarios that are dependant on how the MN receives an IP address. The following scenarios are described:
Scenario 1: The AAA server that authenticates the MN at the ASN GW allocates an IP address to the MN. Note that the ASN GW does not allocate an address from its IP pools.
Scenario 2: The HA assigns an IP address to the MN from one of its locally configured dynamic pools.
Scenario 1: AAA server and ASN GW/FA Allocate IP Address
The following figure and table display and describe a call flow in which the MN receives its IP address from the AAA server and ASN GW/FA.
AAA/ASN GW Assigned IP Address Proxy Mobile IP Call Flow
AAA/ASN GW Assigned IP Address Proxy Mobile IP Call Flow Description
Scenario 2: HA Allocates IP Address
The following figure and table display and describe a call flow in which the MN receives its IP address from the HA.
HA Assigned IP Address Proxy Mobile IP Call Flow
HA Assigned IP Address Proxy Mobile IP Call Flow Description
How Proxy Mobile IP Works in a WiFi Network with Multiple Authentication
Proxy-Mobile IP was developed as a result of networks of Mobile Subscribers (MS) that are not capable of Mobile IP operation. In this scenario a PDIF acts a mobile IP client and thus implements Proxy-MIP support.
Although not required or necessary in a Proxy-MIP network, this implementation uses a technique called Multiple Authentication. In Multi-Auth arrangements, the device is authenticated first using HSS servers. Once the device is authenticated, then the subscriber is authenticated over a RADIUS interface to AAA servers. This supports existing EV-DO servers in the network.
The MS first tries to establish an IKEv2 session with the PDIF. The MS uses the EAP-AKA authentication method for the initial device authentication using Diameter over SCTP over IPv6 to communicate with HSS servers. After the initial Diameter EAP authentication, the MS continues with EAP MD5/GTC authentication.
After successful device authentication, PDIF then uses RADIUS to communicate with AAA servers for the subscriber authentication. It is assumed that RADIUS AAA servers do not use EAP methods and hence RADIUS messages do not contain any EAP attributes.
Assuming a successful RADIUS authentication, PDIF then sets up the IPSec Child SA tunnel using a Tunnel Inner Address (TIA) for passing control traffic only. PDIF receives the MS address from the Home Agent, and passes it on to the MS through the final AUTH response in the IKEv2 exchange.
When IPSec negotiation finishes, the PDIF assigns a home address to the MS and establishes a CHILD SA to pass data. The initial TIA tunnel is torn down and the IP address returned to the address pool.The PDIF then generates a RADIUS accounting START message.
When the session is disconnected, the PDIF generates a RADIUS accounting STOP message.
The following figures describe a Proxy-MIP session setup using CHAP authentication (EAP-MD5), but also addresses a PAP authentication setup using EAP-GTC when EAP-MD5 is not supported by either PDIF or MS.
Proxy-MIP Call Setup using CHAP Authentication
Proxy-MIP Call Setup using CHAP Authentication
a.   If PDIF service does not support Multiple-Authentication and ANOTHER_AUTH_FOLLOWS Notify payload is received, then PDIF sends IKE_AUTH Response with appropriate error and terminate the IKEv2 session by sending INFORMATIONAL (Delete) Request.b.   If ANOTHER_AUTH_FOLLOWS Notify payload is not present in the IKE_AUTH Request, PDIF allocates the IP address from the locally configured pools. However, if proxy-mip-required is enabled, then PDIF initiates Proxy-MIP setup to HA by sending P-MIP RRQ. When PDIF receives the Proxy-MIP RRP, it takes the Home Address (and DNS addresses if any) and sends the IKE_AUTH Response back to MS by including CP payload with Home Address and DNS addresses. In either case, IKEv2 setup will finish at this stage and IPSec tunnel gets established with a Tunnel Inner Address (TIA).
PDIF checks the validity of the AUTH payload and initiates Proxy-MIP setup request to the Home Agent if proxy-mip-required is enabled. The HA address may be received from the RADIUS server in the Access Accept (Step 16) or may be locally configured. PDIF may also remember the HA address from the first authentication received in the final DEA message.
If proxy-mip-required is disabled, PDIF assigns the IP address from the local pool.
Important: For Proxy-MIP call setup using PAP, the first 14 steps are the same as for CHAP authentication. However, here they deviate because the MS does not support EAP-MD5 authentication, but EAP-GTC. In response to the EAP-MD5 challenge, the MS instead responds with legacy-Nak with EAP-GTC. The diagram below picks up at this point.
Proxy-MIP Call Setup using PAP Authentication
Proxy-MIP Call Setup using PAP Authentication
Configuring Proxy Mobile-IP Support
Support for Proxy Mobile-IP requires that the following configurations be made:
Important: Not all commands and keywords/variables may be supported. This depends on the platform type and the installed license(s).
FA service(s): Proxy Mobile IP must be enabled, operation parameters must be configured, and FA-HA security associations must be specified.
HA service(s): FA-HA security associations must be specified.
Subscriber profile(s): Attributes must be configured to allow the subscriber(s) to use Proxy Mobile IP. These attributes can be configured in subscriber profiles stored locally on the system or remotely on a RADIUS AAA server.
APN template(s): Proxy Mobile IP can be supported for every subscriber IP PDP context facilitated by a specific APN template based on the configuration of the APN.
Important: These instructions assume that the system was previously configured to support subscriber data sessions as a core network service and/or an HA according to the instructions described in the respective product administration guide.
Configuring FA Services
Use this example to configure an FA service to support Proxy Mobile IP:
configure
  context <context_name>
     fa-service <fa_service_name>
     proxy-mip allow
        proxy-mip max-retransmissions <integer>
        proxy-mip retransmission-timeout <seconds>
        proxy-mip renew-percent-time percentage
        fa-ha-spi remote-address { ha_ip_address | ip_addr_mask_combo } spi-number number { encrypted secret enc_secret | secret secret } [ description string ][ hash-algorithm { hmac-md5 | md5 | rfc2002-md5 } | replay-protection { timestamp | nonce } | timestamp-tolerance tolerance ]
authentication mn-ha allow-noauth
        end
Notes:
The proxy-mip max-retransmissions command configures the maximum number re-try attempts that the FA service is allowed to make when sending Proxy Mobile IP Registration Requests to the HA.
proxy-mip retransmission-timeout configures the maximum amount of time allowed by the FA for a response from the HA before re-sending a Proxy Mobile IP Registration Request message.
proxy-mip renew-percent-time configures the amount of time that must pass prior to the FA sending a Proxy Mobile IP Registration Renewal Request.
Example
If the advertisement registration lifetime configured for the FA service is 900 seconds and the renew-time is configured to 50%, then the FA requests a lifetime of 900 seconds in the Proxy MIP registration request. If the HA grants a lifetime of 600 seconds, then the FA sends the Proxy Mobile IP Registration Renewal Request message after 300 seconds have passed.
Use the fa-ha-spi remote-addresscommand to modify configured FA-HA SPIs to support Proxy Mobile IP. Refer to the Command Line Interface Reference for the full command syntax.
Important: Note that FA-HA SPIs must be configured for the Proxy-MIP feature to work, while it is optional for regular MIP.
Use the authentication mn-ha allow-noauth command to configure the FA service to allow communications from the HA without authenticating the HA.
Verify the FA Service Configuration
Use the following command to verify the configuration of the FA service:
show fa-service name <fa_service_name>
Notes:
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Proceed to the optional Configuring Proxy MIP HA Failover section to configure Proxy MIP HA Failover support or skip to the Configuring HA Services section to configure HA service support for Proxy Mobile IP.
Configuring Proxy MIP HA Failover
Use this example to configure Proxy Mobile IP HA Failover:
Important: This configuration in this section is optional.
When configured, Proxy MIP HA Failover provides a mechanism to use a specified alternate Home Agent for the subscriber session when the primary HA is not available. Use the following configuration example to configure the Proxy MIP HA Failover:
configure
  context <context_name>
     fa-service <fa_service_name>
        proxy-mip ha-failover [ max-attempts <max_attempts> | num-attempts-before-switching <num_attempts> | timeout <seconds> ]
Notes:
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring HA Services
Use the following configuration example to configure HA services to support Proxy Mobile IP.
configure
  context <context_name>
     ha-service <ha_service_name>
Important: Note that FA-HA SPIs must be configured for the Proxy MIP feature to work while it is optional for regular MIP. Also note that the above syntax assumes that FA-HA SPIs were previously configured as part of the HA service as described in respective product Administration Guide. The replay-protection and timestamp- tolerance keywords should only be configured when supporting Proxy Mobile IP.
     fa-ha-spi remote-address <fa_ip_address> spi-number <number> { encrypted secret <enc_secret> | secret <secret> } [ description <string> ] [ hash-algorithm { hmac-md5 | md5 | rfc2002-md5 } ] replay-protection { timestamp | nonce } | timestamp-tolerance <tolerance> ]
     authentication mn-ha allow-noauth
     authentication mn-aaa allow-noauth
     end
Notes:
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
To verify the configuration of the HA service:
context <context_name>
  show ha-service name <ha_service_name>
Configuring Subscriber Profile RADIUS Attributes
In order for subscribers to use Proxy Mobile IP, attributes must be configured in their user profile or in an APN for 3GPP service. As mentioned previously, the subscriber profiles can be located either locally on the system or remotely on a RADIUS AAA server.
This section provides information on the RADIUS attributes that must be used and instructions for configuring locally stored profiles/APNs in support of Proxy Mobile IP.
Important: Instructions for configuring RADIUS-based subscriber profiles are not provided in this document. Please refer to the documentation supplied with your server for further information.
RADIUS Attributes Required for Proxy Mobile IP
The following table describes the attributes that must be configured in profiles stored on RADIUS AAA servers in order for the subscriber to use Proxy Mobile IP.
Required RADIUS Attributes for Proxy Mobile IP
For Proxy Mobile IP, this attribute must be set to Simple IP.
This attribute must be enabled to support Proxy Mobile IP.
Disabled - do not perform compulsory Proxy-MIP (0)
Enabled - perform compulsory Proxy-MIP (1)
Important: Regardless of the configuration of this attribute, the FA facilitating the Proxy Mobile IP session will not allow simultaneous Simple IP and Mobile IP sessions for the MN.
Configuring Local Subscriber Profiles for Proxy-MIP on a PDSN
This section provides information and instructions for configuring local subscriber profiles on the system to support Proxy Mobile IP on a PDSN.
configure
  context <context_name>
     subscriber name <subscriber_name>
     permission pdsn-simple-ip
     proxy-mip allow
     inter-pdsn-handoff require ip-address
     mobile-ip home-agent <ha_address>
     <optional> mobile-ip home-agent <ha_address> alternate
     ip context-name <context_name>
     end
Verify that your settings for the subscriber(s) just configured are correct.
show subscribers configuration username <subscriber_name>
Notes:
Optional: If you have enabled the Proxy-MIP HA Failover feature, use the mobile-ip home-agent ha_address alternate command to specify the secondary, or alternate HA.
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring Local Subscriber Profiles for Proxy-MIP on a PDIF
This section provides instructions for configuring local subscriber profiles on the system to support Proxy Mobile IP on a PDIF.
configure
  context <context-name>
     subscriber name <subscriber_name>
     proxy-mip require
Note
subscriber_name is the name of the subscriber and can be from 1 to 127 alpha and/or numeric characters and is case sensitive.
Configuring Default Subscriber Parameters in Home Agent Context
It is very important that the subscriber default, configured in the same context as the HA service, has the name of the destination context configured. Use the configuration example below:
configure
  context <context_name>
     ip context-name <context_name>
     end
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring APN Parameters
This section provides instructions for configuring the APN templates to support Proxy Mobile IP for all IP PDP contexts they facilitate.
Important: This is an optional configuration. In addition, attributes returned from the subscriber’s profile for non-transparent IP PDP contexts take precedence over the configuration of the APN.
These instructions assume that you are at the root prompt for the Exec mode:
[local]host_name#
Step 1
configure
The following prompt appears:
[local]host_name(config)#
Step 2
context <context_name>
context_name is the name of the system destination context designated for APN configuration. The name must be from 1 to 79 alpha and/or numeric characters and is case sensitive.The following prompt appears:
[<context_name>]host_name(config-ctx)#
Step 3
apn <apn_name>
apn_name is the name of the APN that is being configured. The name must be from 1 to 62 alpha and/or numeric characters and is not case sensitive. It may also contain dots (.) and/or dashes (-).The following prompt appears:
[<context_name>]host_name(config-apn)#
Step 4
proxy-mip required
This command causes proxy Mobile IP to be supported for all IP PDP contexts facilitated by the APN.
Step 5
Optional. GGSN/FA MN-NAI extension can be skipped in MIP Registration Request by entering following command:
proxy-mip null-username static-homeaddr
This command will enables the accepting of MIP Registration Request without NAI extensions in this APN.
Step 6
end
The following prompt appears:
[local]host_name#
Step 7
Repeat step 1 through step 6 as needed to configure additional APNs.
Step 8
show apn { all | name <apn_name> }
The output is a detailed listing of configured APN parameter settings.
Step 9
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
 
 
Appendix J
Traffic Policing and Shaping
 
This chapter describes the support of per subscriber Traffic Policing and Shaping feature on Cisco’s Chassis and explains the commands and RADIUS attributes that are used to implement this feature. The product Administration Guides provide examples and procedures for configuration of basic services on the system. It is recommended that you select the configuration example that best meets your service model, and configure the required elements for that model, as described in the respective product Administration Guide, before using the procedures in this chapter.
Important: Traffic Policing and Shaping is a licensed Cisco feature. A separate feature license may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the System Administration Guide.
This chapter included following procedures:
Overview
This section describes the traffic policing and shaping feature for individual subscriber. This feature is comprises of two functions:
Traffic Policing
Traffic policing enables the configuring and enforcing of bandwidth limitations on individual subscribers and/or APN of a particular traffic class in 3GPP/3GPP2 service.
Bandwidth enforcement is configured and enforced independently on the downlink and the uplink directions.
A Token Bucket Algorithm (a modified trTCM) [RFC2698] is used to implement the Traffic-Policing feature. The algorithm used measures the following criteria when determining how to mark a packet:
Committed Data Rate (CDR): The guaranteed rate (in bits per second) at which packets can be transmitted/received for the subscriber during the sampling interval.
Peak Data Rate (PDR): The maximum rate (in bits per second) that subscriber packets can be transmitted/received for the subscriber during the sampling interval.
Burst-size: The maximum number of bytes that can be transmitted/received for the subscriber during the sampling interval for both committed (CBS) and peak (PBS) rate conditions. This represents the maximum number of tokens that can be placed in the subscriber’s “bucket”. Note that the committed burst size (CBS) equals the peak burst size (PBS) for each subscriber.
The system can be configured to take any of the following actions on packets that are determined to be in excess or in violation:
Drop: The offending packet is discarded.
Transmit: The offending packet is passed.
Lower the IP Precedence: The packet’s ToS bit is set to “0”, thus downgrading it to Best Effort, prior to passing the packet. Note that if the packet’s ToS bit was already set to “0”, this action is equivalent to “Transmit”.
Traffic Shaping
Traffic Shaping is a rate limiting method similar to the Traffic Policing, but provides a buffer facility for packets exceeded the configured limit. Once the packet exceeds the data-rate, the packet queued inside the buffer to be delivered at a later time.
The bandwidth enforcement can be done in the downlink and the uplink direction independently. If there is no more buffer space available for subscriber data system can be configured to either drop the packets or kept for the next scheduled traffic session.
Traffic Policing Configuration
Traffic Policing is configured on a per-subscriber basis. The subscribers can either be locally configured subscribers on the system or subscriber profiles configured on a remote RADIUS server.
In 3GPP service Traffic policing can be configured for subscribers through APN configuration as well.
Important: In 3GPP service attributes received from the RADIUS server supersede the settings in the APN.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
Configuring Subscribers for Traffic Policing
Important: Instructions for configuring RADIUS-based subscriber profiles are not provided in this document. Please refer to the documentation supplied with your server for further information.
Step 1
Step a
configure
  context <context_name>
     subscriber name <user_name>
        qos traffic-police direction downlink
        end
Step b
configure
  context <context_name>
     subscriber name <user_name>
        qos traffic-police direction uplink
        end
Notes:
There are numerous keyword options associated with the qos traffic-police direction { downlink | uplink } command.
Important: If the exceed/violate action is set to “lower-ip-precedence”, the TOS value for the outer packet becomes “best effort” for packets that exceed/violate the traffic limits regardless of what the ip user-datagram-tos-copy command in the Subscriber Configuration mode is configured to. In addition, the “lower-ip-precedence” option may also override the configuration of the ip qos-dscp command (also in the Subscriber Configuration mode). Therefore, it is recommended that command not be used when specifying this option.
Step 2
context <context_name>
  show subscriber configuration username <user_name>
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring APN for Traffic Policing in 3GPP Networks
This section provides information and instructions for configuring APN template’s QoS profile in support of Traffic Policing.
The profile information is sent to the SGSN(s) in response to GTP Create/Update PDP Context Request messages. If the QoS profile requested by the SGSN is lower than the configured QoS profile configured, the profile requested by the SGSN is used. If the QoS profile requested by the SGSN is higher, the configured rates are used.
Note that values for the committed-data-rate and peak-data-rate parameters are exchanged in the GTP messages between the GGSN and the SGSN. Therefore, the values used may be lower than the configured values. When negotiating the rate with the SGSN(s), the system convert this to a value that is permitted by GTP as shown in the table below.
Permitted Values for Committed and Peak Data Rates in GTP Messages
Step 1
Step a
configure
  context <context_name>
     apn <apn_name>
        qos rate-limit downlink
        end
Step b
configure
  context <context_name>
     apn <apn_name>
        qos rate-limit uplink
        end
Notes:
There are numerous keyword options associated with qos rate-limit { downlink | uplink } command.
Optionally, configure the maximum number of PDP contexts that can be facilitated by the APN to limit the APN’s bandwidth consumption by entering the following command in the configuration:
max-contents primary <number> total <total_number>
Important: If a “subscribed” traffic class is received, the system changes the class to background and sets the following: The uplink and downlink guaranteed data rates are set to 0. If the received uplink or downlink data rates are 0 and traffic policing is disabled, the default of 64 kbps is used. When enabled, the APN configured values are used. If the configured value for downlink max data rate is larger than can fit in an R4 QoS profile, the default of 64 kbps is used. If either the received uplink or downlink max data rates is non-zero, traffic policing is employed if enabled for the background class. The received values are used for responses when traffic policing is disabled.
Step 2
show apn { all | name <apn_name> }
The output is a concise listing of configured APN parameter settings.
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Traffic Shaping Configuration
Traffic Shaping is configured on a per-subscriber basis. The subscribers can either be locally configured subscribers on the system or subscriber profiles configured on a remote RADIUS server.
In 3GPP service Traffic policing can be configured for subscribers through APN configuration as well.
Important: In 3GPP, service attributes received from the RADIUS server supersede the settings in the APN.
Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
Configuring Subscribers for Traffic Shaping
This section provides information and instructions for configuring local subscriber profiles on the system to support Traffic Shaping.
Important: Instructions for configuring RADIUS-based subscriber profiles are not provided in this document. Please refer to the documentation supplied with your server for further information.
Step 1
Step a
configure
  context <context_name>
     subscriber name <user_name>
        qos traffic-shape direction downlink
        end
Step b
configure
  context <context_name>
     subscriber name <user_name>
        qos traffic-shape direction uplink
        end
Notes:
There are numerous keyword options associated with qos traffic-shape direction { downlink | uplink } command.
Important: If the exceed/violate action is set to “lower-ip-precedence”, the TOS value for the outer packet becomes “best effort” for packets that exceed/violate the traffic limits regardless of what the ip user-datagram-tos-copy command in the Subscriber Configuration mode is configured to. In addition, the “lower-ip-precedence” option may also override the configuration of the ip qos-dscp command (also in the Subscriber Configuration mode). Therefore, it is recommended that command not be used when specifying this option.
Step 2
context <context_name>
  show subscriber configuration username <user_name>
Step 3
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Configuring APN for Traffic Shaping in 3GPP Networks
This section provides information and instructions for configuring APN template’s QoS profile in support of Traffic Shaping.
The profile information is sent to the SGSN(s) in response to GTP Create/Update PDP Context Request messages. If the QoS profile requested by the SGSN is lower than the configured QoS profile configured, the profile requested by the SGSN is used. If the QoS profile requested by the SGSN is higher, the configured rates are used.
Note that values for the committed-data-rate and peak-data-rate parameters are exchanged in the GTP messages between the GGSN and the SGSN. Therefore, the values used may be lower than the configured values. When negotiating the rate with the SGSN(s), the system convert this to a value that is permitted by GTP as shown in the following table.
Permitted Values for Committed and Peak Data Rates in GTP Messages
Step 1
Step a
configure
  context <context_name>
     subscriber name <user_name>
        qos rate-limit downlink
        end
Step b
configure
  context <context_name>
     apn <apn_name>
        qos rate-limit uplink
        end
Step 2
Optional. Configure the maximum number of PDP contexts that can be facilitated by the APN to limit the APN’s bandwidth consumption by entering the following command in the configuration:
configure
  context <context_name>
     apn <apn_name>
        max-contexts primary <number> total <total_number>
        end
Notes:
There are numerous keyword options associated with qos rate-limit direction { downlink | uplink } command.
For more information on commands, refer Command Line Interface Reference
If the exceed/violate action is set to lower-ip-precedence, this command may override the configuration of the ip qos-dscp command in the GGSN service configuration mode for packets from the GGSN to the SGSN. In addition, the GGSN service ip qos-dscp command configuration can override the APN setting for packets from the GGSN to the Internet. Therefore, it is recommended that command not be used in conjunction with this action.
Step 3
show apn { all | name <apn_name> }
The output is a concise listing of configured APN parameter settings.
Step 4
Save your configuration to flash memory, an external memory device, and/or a network location using the Exec mode command save configuration. For additional information on how to verify and save configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
RADIUS Attributes
Traffic Policing for CDMA Subscribers
The RADIUS attributes listed in the following table are used to configure Traffic Policing for CDMA subscribers (PDSN, HA) configured on remote RADIUS servers. More information on these attributes can be found in the AAA Interface Administration and Reference.
RADIUS Attributes Required for Traffic Policing Support for CDMA Subscribers
NOTE: It is recommended that this parameter be configured to at least the greater of the following two values: 1) 3 times greater than packet MTU for the subscriber connection, OR 2) 3 seconds worth of token accumulation within the “bucket” for the configured peak-data-rate.
NOTE: It is recommended that this parameter be configured to at least the greater of the following two values: 1) 3 times greater than packet MTU for the subscriber connection, OR 2) 3 seconds worth of token accumulation within the “bucket” for the configured peak-data-rate.
Traffic Policing for UMTS Subscribers
The RADIUS attributes listed in the following table are used to configure Traffic Policing for UMTS subscribers configured on remote RADIUS servers. More information on these attributes can be found in the AAA Interface Administration and Reference.
RADIUS Attributes Required for Traffic Policing Support for UMTS Subscribers
 
 
Appendix K
Sample Configuration Files
 
This appendix contains sample configuration files for the P-GW. The following configurations are supported:
In each configuration example, commented lines are labeled with the number symbol (#) and variables are identified using italics within brackets (<variable>).
Standalone eGTP PDN Gateway
Configuration Sample
# Configuration file for an ASR 5000 in an eGTP P-GW role
#
# Send P-GW licenses
configure /flash/flashconfig/<pgw_license_name>.cfg
end
#
# Set system to not require confirmation when creating new contexts
and/or services. Config file must end with “no autoconfirm” to return the
CLI to its default setting.
#
configure
   autoconfirm
#
# Configure ASR 5000 cards
#
# Activate the PSCs
   card <slot_number>
      mode active psc
      exit
   card <slot_number>
      mode active psc
      exit
# Repeat for the number of PSCs in the system
   end
#
# Modify the local context for local system management
config
   context local
      interface <name>
         ip address <address> <mask>
         exit
      server ftpd
         exit
      ssh key <key> length <bytes>
      server sshd
         subsystem sftp
         exit
      server telnetd
         exit
      subscriber default
         exit
      administrator <name> encrypted password <password> ftp
      aaa group default
         exit
      administrator <name> encrypted password <password> ftp
      ip route <ip_addr/ip_mask> <next_hop_addr> <lcl_cntxt_intrfc_name>
      exit
   port ethernet <slot#/port#>
      no shutdown
      bind interface <lcl_cntxt_intrfc_name> local
      exit
   ntp
      enable
      server <ip_address>
      exit
   snmp engine-id local <id>
   snmp notif-threshold <count> low <low_count> period <seconds>
   snmp authentication-failure-trap
   snmp heartbeat interval <minutes>
   snmp community <string> read-write
   snmp target <name> <ip_address>
   system contact <string>
   system location <string>
# P-GW context configuration
   gtpp single-source
   context <pgw_context_name>
      interface <s5s8_interface_name>
         ip address <ipv4_address>
# note alternative IPv6 address:
         ipv6 address <address>
         exit
      gtpp group default
         gtpp charging-agent address <gx_ipv4_address>
         gtpp echo-interval <seconds>
         gtpp attribute diagnostics
         gtpp attribute local-record-sequence-number
         gtpp attribute node-id-suffix <string>
         gtpp dictionary <name>
         gtpp trigger egcdr max-losdv
         gtpp egcdr losdv-max-containers <number>
         gtpp server <ipv4_address> priority <num>
         gtpp server <ipv4_address> priority <num> node-alive enable
         exit
      policy accounting <rf_policy_name> -noconfirm
         accounting-level {level_type}
         accounting-event-trigger interim-timeout action stop-start
         operator-string <string>
         cc profile <index>
         exit
      subscriber default
         exit
      apn <rf_acct_apn_name>
         accounting-mode radius-diameter
         associate accounting-policy <rf_policy_name>
         ims-auth-service <gx_ims_service_name>
         aaa group <rf-radius_group_name>
         dns primary <ipv4_address>
         dns secondary <ipv4_address>
         ip access-group <name> in
         ip access-group <name> out
         mediation-device context-name <pgw_context_name>
         ip context-name <pdn_context_name>
         ipv6 access-group <name> in
         ipv6 access-group <name> out
         active-charging rulebase <name>
         exit
      aaa group <gz_acct_apn_name>
         bearer-control-mode mixed
         selection-mode sent-by-ms
         accounting-mode gtpp
         gtpp group default accounting-context <aaa_context_name>
         ims-auth-service <gx_ims_service_name>
         ip access-group <name> in
         ip access-group <name> out
         ip context-name <pdn_context_name>
         active-charging rulebase <gz_rulebase_name>
         exit
      aaa group default
         radius attribute nas-ip-address address <ipv4_address>
         radius accounting interim interval <seconds>
         diameter authentication dictionary <name>
         diameter accounting dictionary <name>
         diameter authentication endpoint <s6b_cfg_name>
         diameter accounting endpoint <rf_cfg_name>
         diameter authentication server <s6b_cfg_name> priority <num>
         diameter accounting server <rf_cfg_name> priority <num>
         exit
      egtp-service <egtp_service_name> -noconfirm
         interface-type interface-pgw-ingress
         validation-mode default
         associate gtpu-service <gtpu_service_name>
         gtpc bind address <s5s8_interface_ip_address>
         exit
      gtpu-service <gtpu_service_name>
         bind ipv4-address <s5s8_interface_ip_address>
# note alternative IPv6 address:
         bind ipv6-address <s5s8_interface_ip_address>
         exit
      pgw-servers <pgw_service_name> -noconfirm
         associate egtp-service <egtp_service_name>
         associate qci-qos-mapping <name>
         fqdn host <domain_name> realm <realm_name>
         plmn id mcc <id> mnc <id>
         exit
      ipv6 route <ipv6_addr/prefix> next-hop <sgw_addr> interface <pgw_sgw_intrfc_name>
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <s5s8_interface_name> <pgw_context_name>
      exit
# PDN context configuration
   context <pdn_context_name> -noconfirm
      interface <pdn_sgi_ipv4_interface_name>
         ip address <ipv4_address>
         exit
      interface <pdn_sgi_ipv6_interface_name>
         ipv6 address <address>
         exit
      ip pool <name> range <start_address end_address> public <priority>
      ipv6 pool <name> range <start_address end_address> public <priority>
      subscriber default
      ip access-list <name>
         redirect css service <name> any
         permit any
         exit
      ipv6 access-list <name>
         redirect css service <name> any
         permit any
         exit
      aaa group default
         exit
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <pdn_ipv4_interface_name> <pdn_context_name>
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <pdn_ipv6_interface_name> <pdn_context_name>
      exit
# Enabling active charging
   require active-charging optimized-mode
   active-charging service <name>
      ruledef <name>
         <rule_definition>
               .
               .
         <rule_definition>
         exit
      ruledef default
         ip any-match = TRUE
         exit
      ruledef icmp-pkts
         icmp any-match = TRUE
         exit
      ruledef qci3
         icmp any-match = TRUE
         exit
      ruledef static
         icmp any-match = TRUE
         exit
      charging-action <name>
         <action>
            .
            .
         <action>
         exit
      charging-action icmp
         billing-action egcdr
         exit
      charging-action qci3
         content-id <id>
         billing-action egcdr
         qos-class-identifier <id>
         allocation-retention-priority <priority>
         tft-packet-filter qci3
         exit
      charging-action static
         service-identifier <id>
         billing-action egcdr
         qos-class-identifier <id>
         allocation-retention-priority <priority>
         tft-packet-filter qci3
         exit
      rulebase default
         exit
      rulebase <name>
         <rule_base>
            .
            .
         <rule_base>
         exit
      rulebase <gx_rulebase_name>
         dynamic-rule order first-if-tied
         egcdr tariff minute <minute> hour <hour>(optional)
         billing-records egcdr
         action priority 5 dynamic-only ruledef qci3 charging-action qci3
         action priority 100 ruledef static charging-action static
         action priority 500 ruledef default charging-action icmp
         action priority 570 ruledef icmp-pkts charging-action icmp
         egcdr threshold interval <interval>
         egcdr threshold volume total <bytes>
         exit
      exit
# AAA and policy
   context <aaa_context_name> -noconfirm
      interface <gx_interface_name>
         ipv6 address <address>
# note alternative IPv4 address:
         ip address <ipv4_address>
         exit
      interface <gy_interface_name>
         ipv6 address <address>
# note alternative IPv4 address:
         ip address <ipv4_address>
         exit
      interface <gz_interface_name>
         ip address <ipv4_address>
         exit
      interface <rf_interface_name>
         ip address <ipv4_address>
# note alternative IPv6 address:
         ipv6 address <address>
         exit
      subscriber default
         exit
      ims-auth-service <gx_ims_service_name>
         p-cscf discovery table <#> algorithm round-robin
         p-cscf table <#> row-precedence <#> ipv6-address <pcrf_ipv6_adr>
# note alternative IPv4 address:
         p-cscf table <#> row-precedence <#> ip-address <pcrf_ipv4_adr>
         policy-control
            diameter origin endpoint <gx_cfg_name>
            diameter dictionary <name>
            diameter host-select table <#> algorithm round-robin
            diameter host-select row-precedence <#> table <#> host <gx_cfg_name>
            exit
         exit
      diameter endpoint <gx_cfg_name>
         origin realm <realm_name>
         origin host <name> address <aaa_context_ip_address>
         peer <gx_cfg_name> realm <name> address <pcrf_ip_addr>
         route-entry peer <gx_cfg_name>
         exit
      diameter endpoint <gy_cfg_name>
         origin realm <realm_name>
         origin host <name> address <aaa_context_ip_address>
         peer <gy_cfg_name> realm <name> address <ocs_ip_addr>
         route-entry peer <gy_cfg_name>
         exit
      diameter endpoint <rf_cfg_name>
         origin realm <realm_name>
         origin host <name> address <aaa_context_ip_address>
         peer <rf_cfg_name> realm <name> address <ofcs_ip_addr>
         route-entry peer <rf_cfg_name>
         exit
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <gx_interface_name> <aaa_context_name>
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <gy_interface_name> <aaa_context_name>
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <gz_interface_name> <aaa_context_name>
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <rf_interface_name> <aaa_context_name>
      exit
# QCI-QoS mapping
   qci-qos-mapping <name>
      qci 1 user-datagram dscp-marking <hex>
      qci 3 user-datagram dscp-marking <hex>
      qci 9 user-datagram dscp-marking <hex>
      end
Standalone PMIPv6 PDN Gateway Supporting an eHRPD Network
Configuration Sample
# Configuration file for an ASR 5000 in a PMIPv6 P-GW role supporting an eHRPD network
#
# Send P-GW licenses
configure /flash/flashconfig/<pgw_license_name>.cfg
end
#
# Set system to not require confirmation when creating new contexts
and/or services. Config file must end with “no autoconfirm” to return the
CLI to its default setting.
#
configure
   autoconfirm
#
# Configure ASR 5000 cards
#
# Activate the PSCs
   card <slot_number>
      mode active psc
      exit
   card <slot_number>
      mode active psc
      exit
# Repeat for the number of PSCs in the system
   end
#
# Modify the local context for local system management
config
   context local
      interface <name>
         ip address <address> <mask>
         exit
      server ftpd
         exit
      ssh key <key> length <bytes>
      server sshd
         subsystem sftp
         exit
      server telnetd
         exit
      subscriber default
         exit
      administrator <name> encrypted password <password> ftp
      aaa group default
         exit
      administrator <name> encrypted password <password> ftp
      ip route <ip_addr/ip_mask> <next_hop_addr> <lcl_cntxt_intrfc_name>
      exit
   port ethernet <slot#/port#>
      no shutdown
      bind interface <lcl_cntxt_intrfc_name> local
      exit
   ntp
      enable
      server <ip_address>
      exit
   snmp engine-id local <id>
   snmp notif-threshold <count> low <low_count> period <seconds>
   snmp authentication-failure-trap
   snmp heartbeat interval <minutes>
   snmp community <string> read-write
   snmp target <name> <ip_address>
   system contact <string>
   system location <string>
# P-GW context configuration
   context <pgw_context_name>
      interface <s2a_interface_name>
         ipv6 address <ipv6_address>
            tunnel-mode ipv6ip
               source interface <name>
               destination address <ipv4_or_ipv6_address>
               exit
            exit
         exit
      policy accounting <rf_policy_name> -noconfirm
         accounting-level {level_type}
         accounting-event-trigger interim-timeout action stop-start
         operator-string <string>
         exit
      subscriber default
         exit
      apn <name>
         accounting-mode radius-diameter
         associate accounting-policy <rf_policy_name>
         ims-auth-service <gx_ims_service_name>
         aaa group <rf-radius_group_name>
         dns primary <ipv4_address>
         dns secondary <ipv4_address>
         ip access-group <name> in
         ip access-group <name> out
         mediation-device context-name <pgw_context_name>
         ip context-name <pdn_context_name>
         ipv6 access-group <name> in
         ipv6 access-group <name> out
         active-charging rulebase <name>
         exit
      aaa group <rf-radius_group_name>
         radius attribute nas-identifier <id>
         radius accounting interim interval <seconds>
         radius dictionary <name>
         radius mediation-device accounting server <address> key <key>
         diameter authentication dictionary <name>
         diameter accounting dictionary <name>
         diameter authentication endpoint <s6b_cfg_name>
         diameter accounting endpoint <rf_cfg_name>
         diameter authentication server <s6b_cfg_name> priority <num>
         diameter accounting server <rf_cfg_name> priority <num>
         exit
      aaa group default
         radius attribute nas-ip-address address <ipv4_address>
         radius accounting interim interval <seconds>
         diameter authentication dictionary <name>
         diameter accounting dictionary <name>
         diameter authentication endpoint <s6b_cfg_name>
         diameter accounting endpoint <rf_cfg_name>
         diameter authentication server <s6b_cfg_name> priority <num>
         diameter accounting server <rf_cfg_name> priority <num>
         exit
      lma-service <lma_service_name> -noconfirm
         no aaa accounting
         revocation enable
         bind address <s2a_interface_ipv6_address>
         exit
      pgw-service <pgw_service_name>
         associate lma-service <lma_service_name>
         associate qci-qos-mapping <name>
         authorize external
         plmn id mcc <id> mnc <id>
         exit
      ipv6 route <ipv6_addr/prefix> next-hop <sgw_addr> interface <pgw_sgw_intrfc_name>
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <s2a8_interface_name> <pgw_context_name>
      exit
# PDN context configuration
   context <pdn_context_name> -noconfirm
      interface <pdn_sgi_ipv4_interface_name>
         ip address <ipv4_address>
         exit
      interface <pdn_sgi_ipv6_interface_name>
         ipv6 address <address>
         exit
      ip pool <name> range <start_address end_address> public <priority>
      ipv6 pool <name> range <start_address end_address> public <priority>
      subscriber default
         exit
      ip access-list <name>
         redirect css service <name> any
         permit any
         exit
      ipv6 access-list <name>
         redirect css service <name> any
         permit any
         exit
      aaa group default
         exit
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <pdn_ipv4_interface_name> <pdn_context_name>
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <pdn_ipv6_interface_name> <pdn_context_name>
      exit
# Enabling active charging
   require active-charging optimized-mode
   active-charging service <name>
      ruledef <name>
         <rule_definition>
               .
               .
         <rule_definition>
         exit
      ruledef <name>
         <rule_definition>
               .
               .
         <rule_definition>
         exit
      charging-action <name>
         <action>
            .
            .
         <action>
         exit
      charging-action <name>
         <action>
            .
            .
         <action>
         exit
      rulebase default
         exit
      rulebase <name>
         <rule_base>
            .
            .
         <rule_base>
         exit
      exit
# AAA and policy
   context <aaa_context_name> -noconfirm
      interface <gx_interface_name>
         ipv6 address <address>
# note alternative IPv4 address:
         ip address <ipv4_address>
         exit
      interface <gy_interface_name>
         ipv6 address <address>
# note alternative IPv4 address:
         ip address <ipv4_address>
         exit
      interface <s6b_interface_name>
         ip address <ipv4_address>
# note alternative IPv6 address:
         ipv6 address <address>
         exit
      interface <rf_interface_name>
         ip address <ipv4_address>
# note alternative IPv6 address:
         ipv6 address <address>
         exit
      subscriber default
         exit
      ims-auth-service <gx_ims_service_name>
         p-cscf discovery table <#> algorithm round-robin
         p-cscf table <#> row-precedence <#> ipv6-address <pcrf_ipv6_adr>
# note alternative IPv4 address:
         p-cscf table <#> row-precedence <#> ip-address <pcrf_ipv4_adr>
         policy-control
            diameter origin endpoint <gx_cfg_name>
            diameter dictionary <name>
            diameter host-select table <#> algorithm round-robin
            diameter host-select row-precedence <#> table <#> host <gx_cfg_name>
            exit
         exit
      diameter endpoint <gx_cfg_name>
         origin realm <realm_name>
         origin host <name> address <aaa_context_ip_address>
         peer <gx_cfg_name> realm <name> address <pcrf_ip_addr>
         route-entry peer <gx_cfg_name>
         exit
      diameter endpoint <gy_cfg_name>
         origin realm <realm_name>
         origin host <name> address <aaa_context_ip_address>
         peer <gy_cfg_name> realm <name> address <ocs_ip_addr>
         route-entry peer <gy_cfg_name>
         exit
      diameter endpoint <s6b_cfg_name>
         origin realm <realm_name>
         origin host <name> address <aaa_context_ip_address>
         peer <s6b_cfg_name> realm <name> address <3gpp_aaa_ip_addr>
         route-entry peer <s6b_cfg_name>
         exit
      diameter endpoint <rf_cfg_name>
         origin realm <realm_name>
         origin host <name> address <aaa_context_ip_address>
         peer <rf_cfg_name> realm <name> address <ofcs_ip_addr>
         route-entry peer <rf_cfg_name>
         exit
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <gx_interface_name> <aaa_context_name>
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <gy_interface_name> <aaa_context_name>
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <s6b_interface_name> <aaa_context_name>
      exit
   port ethernet <slot_number/port_number>
      no shutdown
      bind interface <rf_interface_name> <aaa_context_name>
      exit
# QCI-QoS mapping
   qci-qos-mapping <name>
      qci 1 user-datagram dscp-marking <hex>
      qci 3 user-datagram dscp-marking <hex>
      qci 9 user-datagram dscp-marking <hex>
      end
 
 
Appendix L
P-GW Engineering Rules
 
This appendix provides PDN Gateway-specific engineering rules or guidelines that must be considered prior to configuring the ASR 5x00 for your network deployment. General and network-specific rules are located in the appendix of the System Administration and Configuration Guide for the specific network type.
The following rules are covered in this appendix:
Interface and Port Rules
The rules discussed in this section pertain to the Ethernet 10/100 line card, the Ethernet 1000 line card and the four-port Quad Gig-E line card and the type of interfaces they facilitate, regardless of the application.
S2a Interface Rules
This section describes the engineering rules for the S2a interface for communications between the Mobility Access Gateway (MAG) service residing on the HSGW and the Local Mobility Anchor (LMA) service residing on the P-GW.
LMA to MAG
The following engineering rules apply to the S2a interface from the LMA service to the MAG service residing on the HSGW:
P-GW Context and Service Rules
The following engineering rules apply to services configured within the system:
Caution: Large numbers of services greatly increase the complexity of management and may impact overall system performance (i.e. resulting from such things as system handoffs). Therefore, it is recommended that a large number of services only be configured if your application absolutely requires it. Please contact your local service representative for more information.
P-GW Subscriber Rules
The following engineering rule applies to subscribers configured within the system:
 
 
 

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883